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...
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?.
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 encountered this error when I am adding the DAI.dll to the assets folder.
this error happens when I try to build.
UnityException: Failed to run reference rewriter with command --target="Temp\StagingArea\DAI.dll" --additionalreferences="Temp\StagingArea","C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0\Facade","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\1.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.Calls.CallsVoipContract\3.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\2.0.0.0","C:\Program Files (x86)\Windows Kits\10\References.....(followed by alot more of this)....
I am using visual Studio 2017 version 15.7.3 and Unity version 2017.2.0b7
I have added the DLL to the assets folder in unity.
These are my player and build settings.
You need to change the settings in unity (Settings example in the photo below):
Find your dll file in your project inside Unity.
Click on it once to highlight it.
You will see the dll options in the Isnpector
Usually for HoloLens, you only select "WSAPlayer"
Click Apply to save settings.
Rebuild
Warnings
Sometime the dll that you trying to include is referencing something else is not included and that's why it will not work, but the error will be different than what you got.
Sometimes you may need to import an older version of the DLL. For example, I tried to import Newtonsoft.Json 11.0.2, but 11.0.2 was referencing a newer core framework than the solution that unity generate. There is a way to update it, but I didn't want to deal with it every time, so I found out that the highest version that I can use is 9.0.1 (I had to skip 11.0.2, 11.0.1, 10.0.3, 10.0.2, 10.0.1).
Also, keep in mind that you should include netstandard dll.
I usually have UWP test project in hand to try to test my dll with it. If it works there, then it is a good first step that it may work after importing it to Unity assuming it does not have dependencies.
Last result workaround
You can comment the code that references your dll
build the project from unity without the dll
in the generated UWP solution, you can add dll normally and even use nuget to install your desired dll
Uucomment your code.
Build your solution then deploy to your device or create a package to deploy it to device or store.
This works nicely as a work around.
One issue with this is that you will need to import dll or install nuget every time solution generated if it was deleted. It gets annoying and if you are working with a team, it can get confusing when they get the project and think that it does not work. Meaning you need to do more work to communicate and deploy.
Second issue, Unity is moving away from .NET backend to IL2CPP (I don't think you can do this in the CPP generated project). Meaning this is a short term workaround.
Consider upgrading to Unity 2018.2
Using .NET 4.X instead of .NET 3.4 Equivalent made my life easier with references and issues related to references and using more modern C# code.
You can install it and still keep the 2017 version if you install Unity Hub. This will minimize the risk of considering the update.
Last year, I asked the question how to solve a DllNotFoundException for sharpdx_direct3d11_effects_x64.dll with SharpDX.Direct3D11.Effects.dll version 3
Now I'm trying the same thing with version 4.
I was expecting the two DLLs sharpdx_direct3d11_effects_x64.dll and sharpdx_direct3d11_effects_x32.dll to be added to the Visual Studio project but they are not.
Has the deployment mechanism for these two DLLs changed?
Has the deployment mechanism for these two DLLs changed?
Yes, the author of this package xoofx has changed deployment mechanism for these two DLLs from the version 4.0.0-ci120. You can check the the 4.0.0 release notes about Updated D3D11.Effects to the new project system..
Besides, you can download two version of this packages, check the different with NuGet Package Explorer:
According to the official document: Supporting multiple .NET framework versions:
If you have architecture-specific assemblies, that is, separate assemblies that target ARM, x86, and x64, you must place them in a folder named runtimes within sub-folders named {platform}-{architecture}\lib{framework} or {platform}-{architecture}\native.
So the change in the deployment mechanism is correct.
OK I got this to work thanks to #Leo-MSFT's answer above.
I had to download the NuGet package from here.
Rename to *.zip and unzip
Copy the folders runtime/win-x64/sharpdx_direct3d11_1_effects.dll and runtime/win-x86/sharpdx_direct3d11_1_effects.dll to my project and set to Copy Always
This didnt' work so I now copied win-x64/sharpdx_direct3d11_1_effects.dll to the project root and renamed as win-x64/sharpdx_direct3d11_1_effects_x64.dll and set to Copy Always and it worked.
I'm sure this isn't intentional so I've reported a bug to SharpDX on Github.