We recently setup a local nuget server to improve our handling of dependencies within our projects. To package and push our libraries, we use the "new" project format in Visual Studio and a marketplace addon called NuPack-Nuget Packager.
Workflow for development is then to create a new project and pull the required dependencies.
Now we got a strange behavior on all workplaces.
Eg. we have 2 libraries: LibA (Version 1.1.0) and LibB (Version 2.5.0)
where LibB depends on LibA and references it as a project reference.
I have my project referencing LibB (Version 2.5.0) via Nuget.
When I change LibB (now Version 2.5.1) and push it to our Nuget and update the reference in my project everything appears to work fine, the project builds and has no errors, but at runtime, once code is executed that references LibA (still Version 1.1.0, no changes made) I get a FileNotFound Exception: Assembly LibA, AssemblyVersion 1.1.0 could not be found.
The only workaround for now is to package a new LibA as Version 1.1.1 (no code changes) and push it to the nuget server and update the reference in my project to Version 1.1.1 .
Does anyone know a cause / a solution to this?
EDIT Things that do not solve the problem:
Clean / Rebuild the solution (neither Dependencies nor Project)
Update-Package -reinstall in package manager commandline
Clearing Nuget caches and restoring all dependencies
Removing and readding nuget reference in project by hand
EDIT Exact error message (Assembly name changed)
System.IO.FileNotFoundException: 'Could not load file or assembly 'Lib.A.Namespace.1.1, Version=1.1.7, Culture=neutral, PublicKeyToken=null'. Das System kann die angegebene Datei nicht finden.'
Translation of the last part: "File could not be found"
EDIT All dependencies are compiled as AnyCPU for NetStandard2.0
Problem has been identified.
NuPack-Nuget Packager is 'at fault' here.
For anyone stumbling upon this in the future:
Our problem was the way the NuPack-Nuget Packager works.
While the workflow seems to be handy (set Assemblyversion, set output dir, set nuget server, finished), the project will not be build for the package deployment and thus relies on the previous build, which internally still holds the previous AssemblyVersion.
We finally got to the solution after finding out we were pulling obsolete references (found in the User/.Nuget/Packages folder).
We did not come up with a final, one step solution for build, package and deploy yet.
Related
I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)
A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.
you already checked the files app.config and packages.config, and the dotnet framework version?
Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.
I've been stuck with this bug after merging two branches together. The solution builds with no issues, but as soon as I call any function that uses Newtonsoft.Json I get the following exception at runtime:
Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I've looked around and have tried:
Re-installing the nuget package on the affected project
Re-installing the nuget package on all projects running Newtonsoft.Json
Updating all projects in the solution to be the same version of Newtonsoft.Json, then cleaning and
rebuilding the solution
Digging through .csproj files to find Newtonsoft references and manually updating them to the same
version.
When I manually copy and paste the 6.0.0.0 dll into the debug folder I get no issues, however as soon as I clean/ rebuild Visual Studio puts the wrong dll version into the folder again. Even after updating the Nuget package in the affected project to the latest version of Newtonsoft.Json the error still states that it is looking for version 6.0.0.0 rather than 12.0.0.0.
Am I missing something? Any help would be appreciated.
EDIT:
Using .net Framework 4.7
Just to clarify: when I say "wrong dll" I meant it puts the dll that I want it to use in the bin folder (12.0.0.0), but the program see's it as the wrong version, expecting version 6.0.0.0.
Was finally able to get it working. Ditched 12.0.0.0 completely, does not seem that there is a way to get Microsoft.AspNet.WebApi.Client working with any version beyond 6.0.0.0
A project I am working on depends on a NuGet package. The dll file inside package is compiled in Release mode, therefore using debugger to inspect code (which is my goal) is impossible.
I'd like to replace the .dll file with the one I compiled in Debug mode. If I remove the package via NuGet and then add it via Add Reference, I get error:
Assembly 'AssemblyName' with identity 'AssemblyName, Version=4.2.5.0, Culture=neutral, PublicKeyToken=null' uses 'System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cf7b13ffcb2dde54'
which has a higher version than referenced assembly 'System.Memory' with identity 'System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cf7b13ffcb2dde54'
What is the correct way to replace a NuGet package .dll with another .dll file? Where can the version number be changed I am using Rider, but learning how to do it in other IDEs is also useful.
This happens because the nuget is using a specific version of "System.Memory, Version=4.0.1.1", and you have System.Memory, Version=4.0.1.0 referenced in your project. You should update that reference and it should be good. So the problem is with your DLL not the NuGet. Probably when you removed the nuget you downgraded System.Memory, you should update that explicitly to the version that the error says it requires through NuGet.
Pro Tip if you want to mess around with nugets:
It is essentially a ZIP file
Download Nuget
Change extension to .zip
Decompress
Voila, you have some dll-s
You could ask the author of the nuget package to publish source and debug symbols of the package to a public symbolsource server and reference it. After that you would keep using the release version of the dll but be able to debug into it.
I'm getting two build errors in a pull request branch...
Type universe cannot resolve assembly: System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Cannot resolve Assembly or Windows Metadata file 'System.Runtime.dll'
I am working with a Universal Windows Platform project which has the following NuGet packages in its references sometimes:
Microsoft.NetCore.UniversalWindowsPlatform
Microsoft.ProjectOxford.Face
WindowsAzue.Storage
I was reviewing a pull request in a different directory and these did not appear in the references. They do however appear in the NuGet Package Manager. I can install them and uninstall them, but they do not appear in the References for the project in VS 2017.
Build Clean with deleting bin and obj directories and then rebuild does not resolve this build error.
Reinstalling the NuGet packages does not resolve it either.
A stranger mystery to me is where the NuGet Package Configuration for Windows Universal is kept? My hope was that I could manage them with packages.config, and then expect to see them in the packages directory under my project directory. Neither of these things exist in the solution. Have these things changed with NuGet 3? I think understanding this is key.
My project can successfully be built, packaged, and deployed from code in the master branch. It is just this pull request that seems to fail.
The only difference between the branches that appeared to be significant was with the project.json and project.lock.json, which I copied over to no avail.
EDIT
After reading this post https://stackoverflow.com/a/44917060/117995, I decided to remove the project.json file which I had just copied.
Curent status
I have got the following setup (simplified example):
MySolution
┠ MyPclLibrary (PCL targeting .NET Standard 1.3)
┃ ┗ Referencing Microsoft.EntityFrameworkCore.Sqlite (NuGet package)
┕ MyAndroidApp (Xamarin Android)
┗ Referencing MyPclLibrary
In other words MyAndroidApp references MyPclLibrary which in turn references Microsoft.EntityFrameworkCore.Sqlite installed as a NuGet package. I work with Visual Studio 2015 Update 3 on a Window 7 SP1 machine.
The problem
Now the problem is that when I try to build the solution I get the following error message:
Exception while loading assemblies: System.IO.FileNotFoundException:
Could not load assembly 'Microsoft.EntityFrameworkCore.Sqlite,
Version=1.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Perhaps it doesn't exist in the Mono for Android profile?
I have already checked the MyAndroidApp\bin\Debug directory and I can see that the Sqlite DLL has NOT been copied to the output directory.
Of course, MyAndroidApp does NOT make direct calls to Microsoft.EntityFrameworkCore.Sqlite. Instead, MyPclLibrary is responsible for communication with Sqlite.
My best guess it that this problem is somehow related to the new dependency management based on project.json (MyPclLibrary uses project.json while MyAndroidApp uses packages.config).
What have I already tried?
Direct reference (works but is not acceptable): An easy fix would be to add reference to Microsoft.EntityFrameworkCore.Sqlite directly from MyAndroidApp - so make the library a first class reference. However this completely defies the solution architecture and therefore is not acceptable.
Dummy class: I thought the problem might be that there is no obvious usage of the Sqlite (as it is basically a set of extension methods). Therefore I created a dummy class with a single method which enforces a call to the Sqlite so the Sqlite may not be optimized out - to no avail.
No Linker in Adnroid Options: I have set the Project Properties (of MyAndroidApp) -> Android Options -> Linker -> Linking to None as Android Linker may ignore some assemblies that are used solely dynamically - again, to no avail.
Question
How can I use a secondary reference within a Xamarin Android project? I might have missed something really stupid so I am open to any suggestions.
There are two different ways of dependency management, just as your guess it. MyPclLibrary project use MyPclLibrary. deps.json to merge compilationOptions from the input project.json, while MyAndroidApp project use the packages.config to copy the reference dll to bin folder directly. So we could not copy the Sqlite DLL from the MyPclLibrary. deps.json to the MyAndroidApp\bin\Debug directory.
The workaround for this issue is that add reference to Microsoft.EntityFrameworkCore.Sqlite directly from MyAndroidApp (Just as you have already tried). The default behavior for Building Android Apps with Entity Framework is add the Sqlite NuGet packages to the Android project.