Visual Studio interfaces with NuGet via a dll, but the command line tool is solely an exe (nuget.exe).
Is there a reason they don't share a common library? It seems like this introduces the risk of allowing for code divergence between the dll and exe.
Visual Studio and NuGet.exe share a common library called NuGet.Core.dll. Things have changed a bit with NuGet 3.0 but they still share dlls.
The NuGet.exe has the NuGet.Core.dll merged into it instead of having a separate file.
Related
I have a visual studio solution (microsoft visual studio professional 2017) with a main project, that uses classes from a DLL project in the same solution.
The DLL is a "class Library (.NET framework).
Main project is (for my preliminary investigations) a console app. Future versions will be a WPF. I think that the problem appears on all applications that use DLLs that use other DLLs.
The DLL uses other DLLs from a Nuget package. In this case: SQLite. I want to hide to my main project that my DLL uses Sqlite. That makes it possible to change it in future versions to a different database, or maybe use entity framework to access the data.
So my main project only knows that it uses the DLL in the same solution. It does not know that this DLL uses other DLLs.
Problem: These other DLLS are not copied to my main application folder.
This has been asked before: Copying a DLL's dependencies in Visual Studio
The answer says that you should use classes from the Sqlite to make sure the DLLs are copied. That is just what I wanted to prevent: users of my DLL should not have to know that this DLL uses SQLite
That question is 11 years old.
I wonder if Visual Studio has now a better solution for this.
A method to solve the problem was given in Install and manage packages in Visual Studio using the NuGet Package Manager. It is not ideal, the main project still needs to know that the other projects use certain Nuget packages, but at least you don't have to edit the .csproj files, nor type command lines
MySolution
MyMainProject. Refers to MyDll
MyDll. Uses Nuget packages
In Visual Studio. Menu - Tools - Nuget Package Manager
The window that opens shows the installed Nuget packages. If you click on them, you can see on the right the projects that use these packages.
For all installed packages that your main program complains that it is missing at run time, check the box near MyMainProject. At the bottom click Install.
Alas, I'd rather have something in project MyDll that tells everyone who uses this DLL that they also need these Nuget packages. But for the time being I'll use this method.
Will check again in 11 years if there is any improvement.
I am trying to use some references in Visual Studio, I have installed NuGet to use some libraries.
Is there a way to use only part of the package installed with NuGet? For example, if I am using TeklaOpenApi and the following .dll files are installed with this package:
TeklaModel
TeklaDialog
TeklaDrawing
Use for example just TeklaModel, could I do this using NuGet?
Is there a way to use only part of the package installed with NuGet?
I am afraid that you cannot get what you want. It is designed by nuget package. Usually, when the nuget package contains other dlls which means they are probably depended on a master DLL, or used at runtime.
All of them play an important role in this nuget, so we cannot easily remove them.
Although we can use Assembly Reference format(Right-click on References-->Add Reference--> choose one Dll) to reference the specific dll, but there is a risk that if the DLL depends on other corresponding DLL, an error will be reported. So we don't recommend it.
The best way is to install the whole nuget package with all the related dlls.
Hope it could help you.
I'm building a Windows Installer for a VS2015 project.
VS2015 includes the Merge Modules needed to put the VS2015 runtime library into the installer package, however there are DLLs that I didn't compile that have dependencies on older visual studio runtimes.
I don't have the merge modules for these runtimes in the VS2015 library and so far the only way I've seen suggested is to install previous versions of Visual Studio. This is a tremendous pain, because I'll end up with three, extra, different versions of Visual Studio on my machine (to go with the 2015 and 2017 I've already got).
Surely there must be a handy repository to download old merge modules from?
Fire up a VM, install and grab file files. Shouldn't take long at all.
Honestly though I caution against using merge modules. That's a legacy approach with various issues. A better safer approach is to create a bootstrapper and redist the vcredist.exe packages instead.
We are going to publish one of our commercial components, a .NET grid control, as a NuGet package. The product is separated into 2 DLLs - one is the core functionality, and the other is the design-time support assembly. The core assembly can be redistributed as a "normal" DLL and can be placed into any location. But to make the whole product work properly in VS IDE, the design-time part should be installed into a special folder like the Visual Studio PrivateAssemblies folder or into any folder with a special registry key that points to it. Do NuGet packages allow us to do this?
You need to use Chocolatey packages for a run-time dependency like this. NuGet packages are [designed for] for build-time dependencies only.
See http://chocolatey.org/ - Chocolatey uses NuGet under the hood, but has a different focus. You'd probably use NuGet for the "anywhere" DLLs, and a separate Chocolatey package for the VS designer support.
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.