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.
Related
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?.
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.
I have created a system which loads dynamically a library and executes it's main class.
Everything works perfect, the problem I have is how to publish this DLL with all it's dependencies. As no executable project is referencing it I have to manually retrieve the dependencies: try to load the library, check the needed DLL's, go to the NuGet cache folder, copy the libraries, try again, check if it complains about more dependencies and so on until it has all the required libraries.
This is a true pain and I haven't found any information on how to do this, is it possible or am I stuck with this?
The library is a .net standard 2.0 library, I did this before with .net classic and the output folder always contained all the required libraries even the ones comming from a NuGet package, but with .net standard something has changed and now only libraries from referenced projects are being copied, no referenced NuGet package is being copied to the output folder.
Cheers.
Try:
dotnet publish
All the dependent libraries should be copied to the publish output folder.
At the time of writing, it looks like it's by design and there's quite some fuss and confusion about it, see logged issue on GitHub.
Moreover, when publishing a NuGet package for project A referencing project B,
B becomes a NuGet dependency in A; B's assemby is not included in A's NuGet package.
I deal with it by publishing my own NuGet packages.
I only don't like it to have a NuGet package for project B if that one is only relevant to be used with/by project A, as it will appear seperately in my NuGet feed.
TLDR: Convert your Class Library project into an Application, publish the application, and use application DLL as a library.
The long of it:
I tested this approach by deploying a full build with a plugin with many external dependencies to Ubuntu 18.04 and it ran perfectly.
Create a new project of type Console Application instead of Class Library. Put all your library code files into the Console Application and add the dependencies. Get rid of your original Class Library project (you don't need it anymore). Finally, publish the Console Application. You will get a DLL with all of the dependencies. You can use this DLL like any other DLL.
I suggest naming the console app project with "Library" on the end of it and adding a README just to document its not really an application even though the project is configured to build as one.
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...
Maybe Relevant information: I have a web application I built with .net 4.5. I wanted to deploy to Azure's Web Sites but it only supports .net 4.0 so I downgraded the project to .net 4.0.
It still works when run locally.
When I publish to Azure, i get this error:
Could not load file or assembly 'System.Net.Http' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have tried removing the Web API with nuget and readding it, as another question on SO suggested but I still have the same problem.
I have tried close/open VS, and clean/build.
I solved a similar problem (System.Web.Http and System.Net.Http.Formatting) error by removing the reference to problem reference (which was pointed to my .Net installation folder) and replacing it with the reference file in my packages folder that was installed by the Microsoft.AspNet.WebApi NuGet package.
I had the same problem. However, updating assembly versions, copy local, and specific version settings alone did not solve my problem. In my application configuration I deploy a web and a worker role to a cloud service. After creating the service, on the configure tab I set the Operating System to Windows Server 2012 R2 to get the support for .Net Framework 4.5.1. But the error still occured.
Upon further research, I found that the *.cscfg file for my cloud service overrode the portal setting with an obscure osFamily setting of "3". When I started my project it was on MVC3 and did not yet have WebAPI and framework 4.5.1. osFamily 3 was the latest at the time.
In my latest deployment I had upgraded my site to 4.5.1 framework and MVC5. I verified it worked locally on my development machine. But it didn't work after deployment with the error referencing System.Net.Http.Formatting version 4.0.0.0 not being found. I later saw the deployment log that showed the source error
"The feature named NetFx451 that is required by the uploaded package is not available in the OS * chosen for the deployment."
Here is the blog article that led me to the solution to change the osFamily setting to 4. Then my site worked after a fresh deployment.
http://tech.trailmax.info/2014/02/azure-deployment-the-feature-named-netfx451-that-is-required-by-the-uploaded-package-is-not-available-in-the-os-chosen-for-the-deployment/
System.NET.HTTP.dll only depends on System.dll, System.Core.dll and mscorlib.dll.
Make sure you have this DLL (System.NET.HTTP.dll) in your deployment package (you can do RDP connect and check deployment folder). Play with "Copy to Local" property of reference, or include this dll in your project on root level and set type "content" in properties.
Also System.Net.Http.dll is also supported for .NET 2.0 as i see - that might cause an issue. So additionally to above try to set property of reference "Specific version" = true
Azure Now supports .Net 4.5 on the configuration tab you can select .Net framework version V3.5 or V4.5 I have several MVC Web Apps with Numerous supporting DLLs all all compiled in V4.5. What Azure does not support is V 4.5.1 (from the VS 2013 RC release).
I had the same issue with an asp.net application with some Web Jobs which deployed to the same Azure App Service. It was solved by referencing the same System.Net.Http (nuget package) from all projects.
If all of the options you did didn't work, please try restarting (close / open as "admin") your visual studio, then clean / rebuild. This has fixed my problem.
Though this is only for my local machine, haven't tried yet with other environments like in azure or in any server.
I had the same experience with missing System.Net.Http issue.