When I publish my application (using Visual Studio), I always end up with the same (old) NuGet package version of a library, i.e. the updated package does not get published, therefore will not be installed and therefore the application crashes on startup (after being updated) as the required dependency was not found.
That's how my solutions looks like:
Solution\
LibraryProject (with NLog (5.0.0-preview.1) added/updated via NuGet)
MainAppProject (gets published)
Before updating the NLog library, it was at version 4.7.10. That's the version the first published version of the App was shipped and installed with.
Now after I updated the NuGet package, the publish process still ships the old 4.7 version (looking at the dll file properties in the publish folder). Yet in all bin\ and obj\ folders I see the new dll.
Also, in the output of the publish build, I see the new version used:
2>-r:"C:\Users\dev\.nuget\packages\nlog\5.0.0-preview.1\lib\netstandard2.0\NLog.dll"
I also switched to "Produce single file", which deletes the .dll files in the publish folder, also without any success. Switching back to non-single file also results in the old version published again.
Any ideas what I'm missing or where the old file version comes from? How can I further debug this issue (can I build with more verbose logging, if so, how?)
(I've also tried the obvious things: cleaning the solution and restarting Visual Studio)
Found it!
Cleaning the solution did not clean the obj\Release\...\R2R (ready to run) folder. That's where the old dll version was. Manually deleting this folder fixed the problem for me.
Related
I have a .net framework project with framework as 4.8. Recently I integrated docuSign 5.12 using a class library and nuget packages. Everything worked fine in development. When I published the exe in server, I am getting could not load file or assembly error. I cleared the references, reinstalled docusign, changed copy to output property to true for all and published again. But same result.
What I noticed is, when installing .net framework in server, it didn’t create a folder called .Netframework in ‘c:\Program Files(x86)\Reference Assemblies\Microsoft’. As the required dependencies missing are system dependencies, they are not copied to published folder.
So, I have another server where .net 4.8 SDK is present and everything worked fine there. My questions are
Why didn’t installation in server didn’t create assemblies?
Do we need to install .net 4.8 SDK for this to work?
How to publish dependencies for these kind of Nuget packages?
I have not added code samples as it is working already. Dependencies are https://www.nuget.org/packages/DocuSign.eSign.dll/5.12.0#dependencies-body-tab.
You can use the publish functionality of VS. It will package your app, including all NuGet dlls and their dependencies and send it to server. If you use Azure - it's integrated into the process. You can even include it in a CI/CD process. But your specific problem can be addressed by just having VS publish the app to your server instead of you manually copying files over there.
As per the comment from Ralf, I checked the references. Found an interesting thing. I already had a binding redirect in the project but, it was added to the class library config file but not the startup project config file. Because of that, my API was referring to old Newtonsoft version. I copied redirect from class library config to my main project config and it started working.
I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
I am working on a vsix project where I need to get information about a local git directory. I am following this article. When I am using LibGit2Sharp library, I am getting an exception as described in following image and error:-
How can I resolve this?
VS version details:
Visual Studio 2019
.Net Framework 4.7.2
LibGit2Sharp is a managed language (.NET) wrapper around a native (C) library, libgit2. It's a P/Invoke layer, plus a layer to give .NET semantics (objects, etc). This means, though, that you require both the LibGit2Sharp.dll (the managed-language side) and the git2-xxxxxxx.dll (the corresponding native library) that it calls into.
The native DLL is part of the LibGit2Sharp.NativeBinaries project that LibGit2Sharp takes a dependency on. It should be installed (transitively) when you install LibGit2Sharp itself. And although it tries to set itself up as a dependency that will be installed in the output directory, since native binaries are not well-understood in the .NET project world, this can sometimes fail, especially for more complex project types like VSIX.
Ultimately, LibGit2Sharp will look for the corresponding native DLL alongside where it's located. So within your output directory, wherever your VSIX is being executed from, try copying the git2-xxxxxxx.dll that is part of the LibGit2Sharp.NativeBinaries project to that location.
Once you've identified the correct location for the git2-xxxxxxx.dll binary to live, you should copy this as part of your installation for the project. (eg Build action: None, Copy to output directory: Copy always)
I had the same issue and I solved it like this:
Copy the dir folder from VisualStudioExtension -> Bin -> Debug -> lib to the root of the VisualStudioExtension project. This folder contains the DLL files required for LibGit2Sharp to work.
Drag the lib folder onto the VisualStudioExtension project in Visual Studio.
Select the dll files, right-click, Properties, and set it to Copy always and include in VSIX.
That worked for me.
LibGit2Sharp has a dependency on the git2-106a5f2.dll which is under [Debug|Release]\lib\win32\[x86|[x64] directory.
If that particular version is missing, you may need to reinstall LibGit2Sharp library, but uninstall LibGit2Sharp.NativeBinaries library between uninstall and install.
The following operations on NuGet packages should help:
Uninstall LibGit2Sharp.
Uninstall LibGit2Sharp.NativeBinaries.
Install LibGit2Sharp.
Note: do not update LibGit2Sharp.NativeBinaries even if there is a newer version.
I got the same issue. It turn out I ignored the dependecies.
Installing its dependency : LibGit2Sharp.NativeBinaries sort out my problem.
For me, I manually installed the Debug and Release VSIX, and tested against regular VS instance and it worked fine. The LibGit2Sharp threw a DllNotFoundException only when debugging my code via the Exp version of Visual Studio 2019.
So I deleted the entire Extensions folder of the Exp verison of Visual Studio. It is the folder where the Exp version of VS installs all Plugins, like other versions of VS:
%AppData%\Local\Microsoft\VisualStudio\16.0_a31c0a3aExp\Extensions
The next time I debugged my VSIX through Visual Studio, it worked. Hope this helps, I think it has something to do with extensions.en-US files inside that folder. Deleting just my plugin folder insted the Extensions folder did nothing.
I have my windows forms application with WindowsAPICodePack but i don't know where should I put the package in the release folder, and without it the program just gives me an error (it's in Hungarian so I don't think anybody can understand, but it said that it can't find the windowsAPICodePack, the version number, culture and publickeytoken) on another PC, on mine it works.
Depending on if your application is using a packages.config file to manage packages or if your project is using package references (PackageReference) will determine path to solution.
When a package is installed it records the package identifier and version into the project file or packages.config file in your solution workspace.
If using a package.config to mange packages then ensure your packages are getting installed in the location as expected, possibly clearing the cache will help to ensure proper version is installed.
find out the packages folder where your application is trying to load the references.
Possibly config binding redirects.
Clear you package cache and reinstall. use the package manager ui for your ‘debug’ and ‘release’ MSBuild configs to ensure the package is being referenced correctly.
Verify your nuget.xml settings file for locations of packages
Read all the version or property values to use for your application. Ensure you are configuring the release target as expected.
Here are some links to help you config the correct setup for your approach:
Package reference via project files
if using - Packages.config settings
Config setting for Nuget
NuGet settings
Note: for simplicity if this is just a school project then just remove all NuGet packages references and find the dll . Then just add reference to dll and check the property to include in output . This will give you a simple folder with all the files needed to run your app from pen-drive
We have written a service to be deployed to Azure. This consists of a DLL with a "Worker Role" class, and an Azure Cloud Service project, as shown below:
The build steps are:
Build the ccproj in "Release" configuration.
Run NuGet "spec", then "pack" to get a .nupkg file
Deploy the .nupkg file to the Azure Cloud Service
This has been working fine for a while, until we upgraded to .NET 4.6.2 and also upgraded several other references, including System.Runtime (now v4.3.1). Now, despite the fact that we have (probably unnecessarily) added a NuGet reference to every single project in the solution, pointing to System.Runtime 4.3.1, the version of System.Runtime.dll that gets deployed is an older version, resulting in DLL hell on the service, which then fails to run. If we manually copy over the correct version of System.Runtime.dll, then everything works again.
Where is this incorrect version of System.Runtime coming from? And how do we convince the offending software/hardware to use the correct version?
UPDATE: Trail is getting warmer. On my development machine, the bin folder of the EventWorker project contains the correct version of System.Runtime.dll. But... the EventProcessor\obj\debug\EventWorker folder contains the old version! I deleted the obj folder and recompiled the project - and the old version of the DLL appears again.
Where is it coming from, and how to fix?
You have the right idea in terms of hunting down the offending DLL. Have you any dependent DLL's which could be using the wrong version? Also, when run locally does it give you the dll conflict warning in the errors window, allowing you to identify where? Take a look at your config file and see if you have a reference to the DLL version in the redirects section, update it or create a new one to point at the latest version.
Well, I fixed it, but I'm not sure why this worked. I removed the NuGet reference to System.Runtime from the EventWorker project. And now the EventProcessorRole is using the correct version of the DLL.
I'll mark this as the answer in the meantime, but if anyone can provide an explanation for this behavior, I'll give you answer credit...