Some dlls are used frequently in some projects in my company. So I already created one package which contain those dll files, let us just say a.dll, b.dll, c.ll and d.dll. Then I install this package via nuget to the project, all those four dll files will be added to the project. But I do not need all of them into each project, I may only need some of them. I try to delete the dll files which do not need. That`s all works fine.
Now my question is that all dll files will be re-added to the project after update that package. Obviously it is annoying to manually delete dll files after each update.
So is there a way for me to choose the dll files which I need to install when I install my package?
Thanks in advance.
So is there a way for me to choose the dll files which I need to install when I install my package?
As aware as I know you could not choose the dll files when you install your nuget package, at least now we can not do it.
According to the nuget official documents:
When we including multiple dll file in the lib folder, nuget will automatically add those dll file into the project as references. This is nuget default behavior. Besides, updating a package simply means installing an updated version, this is equivalent to a re-installed behavior. So all dll files will be re-added to the project include those deleted files.
Since there are only four dll files in your project, I suggest that you can pack each dll files into packages separately. In this case, you do not need to add all dll files into your project, just install what you needed. Besides, we do not need to update the package in order to update one of dll file.
Hope this helps.
Related
Cross platform Xamarin Forms project in Visual Studio and Visual Studio for Mac. The project references Akavache. Akavache has a dependency of akavache.sqlite3. I have made a custom change to a DLL in the akavache.sqlite3 repo and built the DLL locally, and would prefer not to have to switch the whole Akavache package tree over to a custom build for all the Akavache dlls and dependencies. So essentially...would like to continue referencing the NuGet package like normal but "substitute" one DLL on the fly. Or something equivalent like that!
But it needs to be portable too. At first I used a post build copy command to overwrite the "standard" dll that gets put in the TargetDir. That works in the sense that it copies to TargetDir, but for Android copying the DLL into the TargetDir does no good. The DLL is already incorporated into the APK in the TargetDir instead. So it would need to happen some other way. Same basic issue if you used MSBuild instead of a post build command line.
Any thoughts?
FWIW, my current workaround is to copy the DLL over top of the cached NuGet package location. But the problem with this approach is anytime the cache would get cleared/updated it needs to be reapplied. That's also not an obvious step to do, or easily automated, when another developer want to get set up on their machine.
Any .nupkg files are just ZIP files with some metadata, so you can change at the contents. The NuGet Package Explorer should make it a little easier to view the contents.
The NuGet Gallery (e.g. https://www.nuget.org/) has a "Download" link on the left hand side, otherwise just install the package into an empty project and then take a peek.
I have a VS solution with multiple projects, and I'm using Nuget to obtain external references. However, it's important that the package files for one project Not be in the same folder as the packages for the rest of the solution. As such I would like to put them into their own, seperate folder.
It would also be acceptable if all of the packages went into one folder, and then only the ones used by other projects were copied into the folder that they need them to be in. But I don't know of any way to achieve this behavior either.
If it helps, the specific scenario is a Unity project referencing a standard .NET class library project. The solution contains the .csproj file for the library DLL and also the ones generate by Unity. Because unity regenerates those project files every time the Unity project is changed, any packages to be used by those projects need to be inside the Unity project's Assets/ folder, or else the references won't be added to the generated .csproj files.
However, ALL dlls contained anywhere in the Assets/ folder are added to the generated projects, unless manually marked as not to include on a per-file basis. Which is why I don't want the packages referenced by the Library project to end up in that folder, as manually going through and marking every single .dll in every single package not to be used by the Unity project will become very tedious very fast. Especially since some packages download numerous dlls for many different versions of .net.
I have my project set to Allow NuGet to download missing packages as well as Automatically check for missing packages during build in Visual Studio. In my solution folder, there is a packages folder and it contains everything that I need for my project. However the references to them in the project are still broken.
I have tried removing the references and adding them with NuGet, but NuGet says the item is already in the project (it is in the packages folder) even though the reference is there and the project can't build. The only way that I can seem to get around it is to manually go into each of the packages in the packages folder and select every .dll.
Is there a better way to do this?
Open package manager console and type:
Update-Package -Reinstall
This should refresh all your references based on each project's packages.config file.
In my projects folder root, I have a packages folder that is utilized by various web applications at C:/Projects/packages. All application references that point to this folder work fine.
However, with a new application, when I pulled the latest code, all references expect the packages folder to live at the solution level - C:/Projects/CompanyName/Apps/SolutionFolder/packages.
When I pull latest, this folder is not included (it's never checked in to subversion) so I have missing references when I first open a project up. However, when I try to build, it doesn't pull the latest for these packages and of course, doesn't compile. When I run Update-Package -reinstall, it will update the packages IN C:/Projects/packages, and it WILL NOT create the packages folder at the solution level.
I've confirmed that I have the packages.config in each project in the solution and that each project expects that the assemblies will be housed in the packages folder at that level. What's weird is that after I run the -reinstall, these hintpaths in the project files will actually point to the C:/Projects/packages folder and the assembly references will resolve...but only for 3rd party packages and NOT for our in-house built packages.
Does anyone know why this occurs? The solution has been to get a copy of the packages folder that a coworker is using and paste that into the solution folder but that doesn't solve the problem if it occurs again.
Per #MattWards link I checked the nuget.config file in appdata, which specified this C:/project.packages path. After removing this setting and building my solution, the packages folder was added to the solution level and everything worked.
I've got a packages.config file checked into source control. This specifies the exact version of the Nuget dependency I want. We have our own NuGet repository. We are creating these NuGet packages ourselves.
<packages>
<package id="Dome" version="1.0.0.19" targetFramework="net45" />
<package id="Dome.Dojo" version="1.0.0.19" targetFramework="net45" />
</packages>
These packages have some JavaScript files which when you add the Nuget package as a reference in Visual Studio are copied to the Scripts folder in the project.
I don't want to check these JS files in to source control, I just want to check in the packages.config file.
When my project builds in Team City (or when I build in Visual Studio after a fresh checkout) it doesn't copy the JS files from the NuGet package. There's a question here explaining a similar problem:
NuGet package files not being copied to project content during build
But, the solution in the answer to that question doesn't work for me; that solution uses ReInstall, which is problematic because it can automatically upgrade the version in the packages.config file (say if a dependency is specified as a >=).
The whole point of this is that I want to be able to checkout a revision from my source control, and build that version with the right dependencies AND I want to use the nice packaging features of NuGet. So, I don't want any "automatically update to the latest version during the build."
There's an issue against NuGet (http://nuget.codeplex.com/workitem/2094) about NuGet files not restoring content files. And it's Marked as Closed By Design.
Thinking about how this works a little more, it appears to me (but I'm not 100% sure) that for assemblies NuGet has a different behaviour - it doesn't copy them into the project, instead it references them from the location in the packages folder. It strikes me that js files in the NuGet package should be referenced analogous to how dlls are referenced.
Is there a way to construct a NuGet package so that it references the JS as links in the project (in a similar way to how you can add an existing File as a Link in VS)? And would this solve my problem?
If not then I'll take the advice given by Jeff Handley when closing ticked Nuget Issue 2094 mentioned above:
The option you'd have is to create a new console executable that
references NuGet.Core, and you could build a supplemental package
restore for your own use that copies package contents into the
project.
Writing my own command line tool to copy the contents does seem like I'm pushing water uphill here - am I doing something fundamentally wrong?
The underlying problem here is Visual Studio's relatively poor support of JavaScript projects and JavaScript's lack of built-in module loader.
For C#, when you install a package it adds a reference in your .csproj file to the assembly on disk. When you build, MSBuild knows to copy the thing referenced to the bin directory. Since you aren't checking in your bin directory, this all works great.
Unfortunately for JavaScript, the build system isn't nearly as matured and there aren't well defined guidelines for NuGet to follow. Ideally (IMO), Visual Studio would not run web sites directly from your source directory. Instead, when you built it would copy the JavaScript files, CSS and HTML files to a bin directory from which they would be executed. When debugging, it would map those back to the original JavaScript or TypeScript files (so if you make a change it isn't to a transient file). If that were to happen then there is now a well-defined build step and presumably a well-defined tag for JavaScript files (rather than just "content"). This means that NuGet would be able to leverage that well-defined MSBuild tag and package authors could leverage the NuGet feature to do the right thing.
Unfortunately, none of the above is true. JavaScript files are run in-place, If you did copy them to bin on build Visual Studio would do the wrong thing and editing from a debugger would edit the transient files (not the originals). NuGet therefore has no well-defined place to put files so it leaves the decision up to the package author. Package authors know that the average user is just going to be running directly from source (no build-step) so they dump files into the source folder where they must be checked in to version control.
The entire system is very archaic if you are coming from a modern ecosystem like C# where someone took time to think these things through a bit.
What you could do is create an MSBuild task that, before build, would go through all of your packages, look for content, and copy that content to the desired location. This wouldn't be terribly difficult, though would take a bit of work.
Also, package authors could include a build-task that does this in their package so that before-build all of their content was copied local. Unfortunately, if only some package authors do this then you end up with weird fragmentation where some packages need to be committed to version control and others do not.
When a package is installed into a project, NuGet in fact performs these operations,
Download the package file from source;
Install the package into the so called packages folder, which is $(SolutionDir)\packages by default;
Install the package into the project, which consists of adding references to DLLs, copying content files into the project directory etc.
When a package is restored, only the first two steps are executed. Projects will not be touched by nuget package restore. Which is why the js files in your project will not be "restored".
The only solution for now is to check in the js files in your project.
If you are the owner of the package then you could use the nuget package i've created to be able to have a folder called "Linked" in the package and have a simple Install.ps1 and Uninstall.ps1 (one liners) to add every file in the nuget package's linked folder as existing to the project.
https://github.com/baseclass/Contrib.Nuget#baseclasscontribnugetlinked
I didn't try out how publication treats linked files, the problem is debugging the Project, as the JavaScript files will be missing in the directories.
If you are using git as source control you could try my nuget package which ignores all the nuget content files and automatically restores them before building.
Step by step example in my blog: http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0