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.
Related
I want to write that C# code convert-nunit-3-nunit-2-results-xml-file, but despite the added nuget package i'm missing the dll in my project.
I see it in the tool's directory of the package cache, but missing it in my project.
What do i overlook?
My project is at present for .Net Core 2.1. Is my issue therefore related to this: Add support for net standard ?
I'm new to .net and don't understand all the differences so far.
As zivkan explained, the package is a tool. In fact, it's an extension to another tool, the NUnit engine package. The NUnit engine knows how to find and use the extension.
NUnit does not publish a package that is intended for use by your code as a library, because we would then have to support it as a library in addition to it's use as an extension to NUnit.
However, NUnit's MIT license allows you to use the source code, which you can find at https://github.com/nunit/nunit-v2-result-writer
Since the code has not yet been ported to .NET Core, you would have to do that yourself.
You didn't overlook anything. Not all NuGet packages are libraries.
NuGet has conventions on how files must be packed in order to use various features. For example, files in the content or contentFiles get copied into the project directory, or build output, depending if the project using the package uses packages.config, or PackageReference. If the package author wants to give you a library that you can use in your code, they must put the library in the lib directory in the nupkg (technically it could be in ref, but those don't get copied to build/publish output, they're only used at build time). The tools directory is, unsurprisingly, intended for tools packages. It's often used by unit test runners, or in this case, a report generator.
So, since the package puts the dlls in the tools directory, this means the package author intends the package to be a tool to assist you during development, but not as a library for you to use in your code. You could try contacting the package author to see if they have published another package with the same dll, this time in the lib directory, so that you can use it your project.
Otherwise you'll need to find a solution that doesn't rely on NuGet bringing you this dll as a library. One option is to have a packages.config file that extracts the package in a solution packages directory, and then you use a dll reference to the dll. Your build script would then need to first restore the packages.config file before building your project. Another option is to check in the dll into your source control management tool, if the dll's license allows that, and again have a dll reference to it.
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
I'm creating a private NuGet package for my company and I want to distribute two different versions of my .dll. The release .dll was for some developers who can call this dll for development. And the debug .dll id for some developers to develop the dll itself for the second version.
So my question is that if I wanted to accomplish this by using only one NuGet package, is this possible? Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
Any suggestion? Thanks in advance.
Do I have to create a script on the installation of the package that adds references in the MSBuild, or am I overcomplicating things?
To my knowledge, you may overcomplicating this things. That means you want to use one dll for debug mode to test and another dll for release mode to develop, so those two dll files should be independent, which should be distributed to different packages. Because a NuGet package will normally hold just a single set of assemblies for a particular target framework. It is not really designed to ship a debug and release version.
Besides, when we publish nuget package, the release version of your dll is the best choice since users wont debug into your dll, they will only care about if it works fine and how it works.
In addition, NuGet supports use any string as a suffix to denote a pre-release version, as NuGet treats any such version as pre-release and makes no other interpretation. So you can use -beta to specify a new version of that dll for develop.
https://learn.microsoft.com/en-us/nuget/reference/package-versioning#pre-release-versions
Basically per my understanding, use a different version of the package should be better. Of course, if you persist on using one package, Nekeniehl provided the correct direction.
Hope this help you.
You can create the same dll and each team can get the dlls like yournuget -release or yournuget -debug.
I normally use a buildscript to create the nugets, paket and FAKE will help you do the job.
And here a related answer to your question:
How to create a nuget package with both release and debug dll's using nuget package explorer?
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.
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.