Change package installation path at source explorer's level - visual-studio

Is it possible to change path of a nuget package at Source Explorer's level? Suppose, we want to install newest Bootstrap package for your ASP.NET MVC5 project using nuget.
In default it installs its CSS files in ~/Content/ folder. What if I would like the files to be inside ~/Content/Libs/?
Of course I can move them manually, but I would like to keep a possibility of updating the libraries via nuget.

Related

How to install and use the latest Bootstrap in an MVC5 project?

I'm trying to use Bootstrap in my ASP.NET MVC5 project (I'd like to use .NET 5, but Visual Basic is not fully supported yet.)
I installed the latest NuGet package, but no folders/files were added to my project—only the package itself under the References node.
I found this extensive answer, but it's somewhat dated and it addresses a project architecture of ASP.NET Core. I added the suggested Package.json file, but no folder node_modules was added anywhere in my project.
How do I get started using the Bootstrap NuGet package in my MVC5 project?
--EDIT--
I'm using PackageReference, not Packages.config.
For Bootstrap is a client-side library,If you download by Nuget Package Manager, you can find it in the %UserProfile%\.nuget\packages directory. You could copy and paste it to your project.
Actually I suggest you could use LibMan for client-side library.
Here is the steps you could follow:
Create the folder wwwroot/lib;
In Solution Explorer, right-click the project folder in which the files should be added. Choose Add > Client-Side Library.
Search for bootstrap#5.0.2 like below:
Click the Install button to download the files.
Reference:
Use LibMan with ASP.NET Core in Visual Studio
Note:
The js and css are in wwwroot/bootstrap/dist/.

After Installing Microsoft.PowerShell.SDK a "runtimes" folder is added to my project

I added the Microsoft.PowerShell.SDK NuGet package to my project and these folders appeared in it.
Why does it happen?
NuGet 4.0+ with PackageReference supports content files. Content files are used to include artifacts like text files, XML files, images or even C# or VB code in a package that are are included with a predefined build action into the consuming project, optionally with a specific copy action.
The Microsoft.PowerShell.SDK package defines the content folders ref and runtimes that contain psd1, ps1xml files that are included with build action None in your project. They are copied to the output directory if newer. Visual Studio shows them with that little blue link arrow so that you know that they are referenced and not created in your own project.
Below you see the internal structure of the package. The path of the files inside of the package is given by /contentFiles/{codeLanguage}/{TargetFrameworkMoniker}, where any is like a wildcard.
Note that if you install the Microsoft.PowerShell.SDK package in an older project type that uses packages.config you will not see them, because content files are not supported there.

Nuget Packages not installing anything in .net core app

I am trying to install knockoutjs and typescript in a .net core app via Nuget.
It shows in Packages but doesn't install anything in a scripts folder as has previously in asp.net.
What am I missing?
TL;DR ASP.NET Core no longer works in that way (packages copying javascript/css content into your project). You need to adapt your workflow.
.NET Core projects only work in SDK-style projects, and SDK style projects only use NuGet's PackageReference, not packages.config. The docs on migrating from packages.config to PackageReference list one package compatibility issue as not supporting the content folder, which is how in packages.config those assets are copied into your project on package install.
I can't find a doc listing recommendations for ASP.NET Core apps, but my understanding is you can either use LibMan, or use NPM, which is in line with basically the rest of the web development industry outside of .NET has been doing. If you use the new project templates to create a new ASP.NET Core Angular or ASP.NET Core React app, you'll see they create a ClientApp folder that uses npm and all the official react/angular CLI tools. The MVC template has copies of jQuery and bootstrap, without an obvious way how to update them.
might be some unsync, remove the packages folder from the solution and restore the packages again. It will fix the issue. Also check the output window, that will show the list of errors.
It shows in Packages but doesn't install anything in a scripts folder
as has previously in asp.net.
First, I agree with zivkan. It is a feature of PackageReference Nuget Management format.
VS has two format to manage nuget packages: Packages.config and PackageReference.
Since new sdk format projects(Net Core and Net Standard) only use PackageReference to manage nuget packages,it will be very different from the effect reflected by the packages.config package management format.
When you use Content files from the nuget packages with PackageReference, it will lose files from the Scripts folder.
Just as this document said, it has such compatibility issues.
Actually, you can enter C:\Users\xxxx\.nuget\packages\knockoutjs\3.5.1 and find there is a folder called Content, Nuget will copy the content of that folder into your project when you install this nuget package.
But Content folder can be recognized by Packages.config format, and as far as I know, ContentFiles folder is used in PackageReference to add the content into your project. So in your situation, the nuget package should include ContentFiles folder at the same time. See this official document.
But the knockoutjs nuget package does not have contentfiles folder. That is why net framework projects with packages.config has the content files while new sdk projects does not have it.
And this behavior change can only be effective when you create the nuget package, so you ca n’t make any kind of change, you can only contact the author of the package to make this modification, and let him add this function as soon as possible to apply to the new SDK format project.
Suggestion
So So for now, you can try these:
1) you can either manually Add the content file from C:\Users\xxxx\.nuget\packages\knockoutjs\xxxx\Content to the project by Adding Existing Items.
2) roll back to use Net Framework projects with packages.config.
3) contact with the author on this link.

How to include dll,.xml, .txt, .config , pdb and lic files while creating a Nuget package

Using Nuget package explorer i'm creating nuget packages. There i'm directly adding the lib folder and adding the dll's.
can i add config, XML, lic, pdb directly to the package? or is there any way to add these files while creating package?
And there is one file with extension .AseClient. how can i add this file to the package?
we can nuspec for package the assemblies. If i use this process can i add the above mentioned files while creating the package?
If any one wants to create a nuget package by their own they can go with the Nuget Package explorer it is the easiest way to create packages.
In my case i would like to include dll, xml ,pdb and config files and i would like to create the package with the same folder structure that is existing in my local. You can create a package that supports .Net framework version(4.2,4.5,4.5.1).
1)first click on create package
2)Right hand side on the empty space right click and add Lib to the package
3)Right click on Lib and add .net folder with the version you would like to support either 4.2,4.5,4.5.1 based on requirement.
4) right on the folder which you created and add existing folder add the dll, xml files.
5) if there is any child folders just simple right click on the required folder and add folder.

How do I reference instead of copy js files from a Nuget package at build time in TeamCity?

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

Resources