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.
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?.
My computer only has VS2019 installed with .net versions up to 4.8. I'm attempting to use the Microsoft.Build.Construction assemblies in a program i'm working on. When i go to add the reference->Assemblies, the only versions i have are 4.0.0.0. Based on my research, VS stopped adding assemblies to the GAC, so i'm forced to manually add the DLL from C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin in order to utilize the Version 15.1.0.0 that at least supports the SolutionFile calls.
So my question is this: should i push those versions to the GAC in order to be able to use them, or is there a better way to access non-GAC assemblies than how i did.
For MSBuild assemblies, you must follow the guidance of Microsoft strictly to avoid all side efforts. In general, the NuGet packages are recommended.
Change MSBuild references
To make sure that MSBuild loads from a central location, you must not distribute its assemblies with your application.
The mechanism for changing your project to avoid loading MSBuild from a central location depends on how you reference MSBuild.
Use NuGet packages (preferred)
For detailed information, please check out the long reference
Forget the GAC, just take the DLL in the Bin folder, copy it to your project folder in /References, and reference it from there. This way if you use version control, the specific version of the DLL follows the source code.
EDIT: As mentioned by Lex below, this is not a suitable solution for MSBuild assemblies, you should use the Nuget package instead.
i'm trying to obtain an executable file with only the necessary dlls in the release folder, unfortunately VS is putting in that folder even System dlls, that afaik are not supposed to be redistributed with the executable.
I'd like to know if there's a way to make VS add to the release folder only dlls the executable can not work without, the ones that are supposed to be redistributed.
Thank you.
Release folder:
These assemblies are shims for .Net Standard where the full framework had gaps. Based on the assemblies in that folder, I assume that your exe is targeting .net 4.6.x and you are consuming a .net standard library.
If you upgrade to .net 4.7.2 you will see the number of required System.* assemblies reduced greatly.
See this answer for more details: Why does my .NET Standard NuGet package trigger so many dependencies?
I'm assuming this is a dotnet core project. Use the "dotnet publish" command to create your deployment files (the screenshot looks like a VS build directory?). You might see more dlls than you're used too if you're coming to dotnet core from using the Windows frameworks previously, but it depends on the publish options you use.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
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...
I wanted to use two different version same library (OpenCVSharp 2.x and OpenCVSharp 3.x).
I downloaded those two packages both to the separate project (let's call it OCV2Wrapper and OCV3Wrapper) and reference both wrappers in my project. I had to renamed libraries from one package (2.x) and reference them manual because: Can we add 2 different versions of same package in NuGet. I read about external aliases and I used external alias in one of the wrappers (2.x in my case).
But I have some major problems:
My renamed libraries are not copied to the launch project build (that one which reference both wrappers), but is in build of the 2.x wrapper
It doesn't work because yet it says it cannot find a type from my 2.x wrapper even when I manually copy my renamed libraries from 2.x wrapper.
What is the correct approach for this scenario in C#?
I want to use both wrappers in solution because the 2.x version contains algorithms (SIFT and SURF) and 3.x version contains algorithms (Kaze and AKaze).
I can live that with both packages coming from somewhere other than NuGet, but I prefer that 3.x comes from NuGet and the 2.x version is manually configured.
As already stated, there is nothing wrong with referencing 2 different versions of a NuGet package, as long as it's in different Visual Studio Projects that those references are made.
But this is also where the easy part ends, but I think there are a few options left. Depending on your needs, I see the following options.
Create a post build step which registers the multi-versioned assemblies into the GAC. As long as each assembly have different assembly version, the CLR will pick up the right assembly from the GAC when needed.
Create a post build step which copies the different assemblies into a subfolder of your application bin folder like bin/package-v1 and bin/package-v2. Then you can, in your application, override the AssemblyResolve event as described here: https://msdn.microsoft.com/en-us/library/ff527268(v=vs.110).aspx. This will make it possible for you to load the assembly in the right version at the time of need.
If you don't want to play around with AssemblyResolve, then you can also modify your web/app.config to do assembly redirect/probing as described here: https://msdn.microsoft.com/en-us/library/4191fzwb(v=vs.110).aspx
Hope this helps a bit, so you don't have to modify third party source code next time.
OK so, I solve this by downloading whole sourcecode for 2.X wrapper version.
Renamed its namespace to ABCDEF2 where ABCDEF was original namespace. Build my own nuget package with my own key and... publish it to our private nuget server.
This is such a lame solution but there is no other way than manually downloading the original packages and reference it directly with different filename etc and you loose nuget advantages.