When running 'nuget pack' on a web project, I get a lot of errors saying that a file named 'content' is already added into the package.
For example:
WARNING: File 'SlowCheetah.Transforms.targets' is not added because the package already contains file 'content'
WARNING: File 'Web.config' is not added because the package already contains file 'content'
Looking into the generated package, I find out that the 'content' file is actually one of the content files (the first one it finds), so the what the warnings are telling me is that every content file in the project is being packaged as 'content'.
Any thoughts?
At the end what I did was creating the file structure for the nuget package and packaging from there rather than from the project itself. I actually got more control for what's included rather than giving the VS folder the full responsibility for that.
Using this as a reference: https://learn.microsoft.com/es-es/nuget/create-packages/creating-a-package
I recommend creating the tools, lib, content and build folder structure and publish into it from the web project. You can adjust the nuspec file with your dependencies.
Almost 2 years using this approach :)
Related
While looking at the contents of a Nuget package I came across the following file named:
_._
Shown by the Image below:
What does this file mean or do in nuget packages?
They are placeholder files to denote an empty directory.
Empty directories are often not well-supported in ZIPs so a file with that name is placed in there to ensure the directory is created.
From this link
They are placeholder files to denote an empty directory. Empty directories are often not well-supported in ZIPs so a file with that name is placed in there to ensure the directory is created.
This is important because the existence of an "empty" net46 folder
means that the package supports .NET Framework 4.6, but does not
require any assemblies (DLLs) in order to run on that version of .NET.
This is most likely because the implementation of the package is in
the GAC.
Using the really easy to follow instructions for building a NuGet package for an assembly with an associated package of sources for the symbol server, found here on David Ebbo's blog "The easy way to publish NuGet packages with sources" I have indeed created a pair of packages: binary and sources.
However, the sources package is incomplete and the reason is that the sources come from two class library .csproj and I used ILMerge to combine the results of the second into the first. (*) So, using the minimal .nuspec described in this post and pointing nuget.exe at the .csproj for the "main" library, the binary package is fine, but of course the sources package only has sources for the "main" library, not also for the library that was ILMerged into the "main" library.
How do I fix this (and get the sources for both projects included in the symbol package but only the binary for the "main" project in the binary package)?
FYI, the actual nuget.exe command line was: nuget pack CommandLineLexing.csproj -Build -Symbols -Properties Configuration=Release.
(*) The reason I'm doing this, in case you're interested, is that the second library is a cut down version of my accumulated "C# utilities" library - you know, a bunch of extension methods and other helpers - cut down so it only has the bare minimum needed for this particular project. And so, since it is cut down, I don't want there to be separate assembly for it which might eventually get confused with the full assembly (having the same name, and not a strong name). So I used ILMerge to put the utilities methods into the main assembly (and also mark them internal).
Not going to be easy I'm afraid.
NuGet symbol packages are simply your regular package, with pdbs, augmented with source files.
Assuming you already know you can get a merged PDB with ILMerge/ILRepack (/debug), that part is probably working file, I'm assuming your issue is that only the source files from the current project gets included.
You could simply post-process your symbol.nupkg (which is a zip), and include the source files from your other (merged) project in the src folder (you can even try that manually).
Though if you run srctool.exe -r MyMergedAssembly.pdb, you'll see different root paths, where usually (for a non-merged project) they all have a common prefix.
It may work, if SymbolSource copes with having multiple path prefixes in your PDB, that I haven't tried.
I also failed to find any documentation irt to their processing of symbol packages. We can assume they use pdbstr.exe tool to update the PDB srcsrv section of the PDB file to redirect the symbol loading to their website, but one can only tell if they support multiple roots by testing it.
If you upload your augmented symbol package to symbolsource, you can download the updated PDB using a URL similar to http://srv.symbolsource.org/pdb/Public/Castle.Core.pdb/4C81FC30DF584853B9869EAB2FA7D9891/Castle.Core.pd_ (then unzip it to a pdb file)
Then you can use both srctool.exe file.pdb and pdbstr.exe -r -s:srcsrv -p:file.pdb to verify their work.
I'm trying to use the simplest and most automated approach possible to create a few NuGet packages from some of our projects, by using the nuget pack [path-to-csproj] method.
For most of the projects I've tried this, the command line tool seems to understand the .Net framework version of the projects and it adds the output dll and xml files to the correct lib folder. In some other project, it is including a .css file to the content folder in the package, I assume because the file has a Content build action.
What exactly does this NuGet command include in the final package and how does it extract this information? Is there a comprehensive documentation on the file extraction from the csproj? I'd like to understand this process so that I can hopefully add my own files to it, like the app.config file and some code contracts assembly files without having to hardcode paths in the nuspec definition.
I have created a T4 template that I want to reuse in several projects using NuGet. This template is based on a custom class so I need to distribute a DLL with the template. The DLL is used by the template during generation, but is not used by the project itself so I do NOT want it added to the target project as a reference.
My .nuspec file includes my DLL and places it in the root of the package which will prevent it from creating a reference and everything works fine if I build my package by hand. Unfortunately, I want to use the "nuget pack" command to automatically pick up the version number. When I run this command and reference the project file, it includes my DLL twice, once in the root (as I specified in my nuspec file) and an additional time in the lib folder (along with everything in the bin folder).
How can I automatically build my NuGet package without including any references. It seems there are several solutions, but I can't figure any of them out:
Let nuget include my DLL in the lib folder, but prevent it from creating the reference. I know I can use the <references> section to reference some DLLs and not others, but in this case I don't want it to reference any. If I leave the <references> section blank it is either ignored or I get an error depending on what level I leave blank.
Prevent nuget from including any DLLs automatically and only include the files in the <files> section of the nuspec file. Unfortunately, I can't figure out how to build the package from the project file without it including my DLL automatically.
Any thoughts?
If you right-click the DLL, you'll probably see that its "build action" is set to "content". Try setting it to "none".
I am building an MVC4 web application with VS2012 professional with NuGet Package Manager version 2.2.31210. I have multiple projects in my solution, all sharing various packages I installed using NuGet. One of my projects is an MVC4 web application where I am using packages such as bootstrap, jquery UI, etc, all installed using NuGet.
When I clone a fresh copy of my entire solution from my repository and build my MVC4 project, the package restore feature seems to be working: it creates the packages directory under the solution direcotry and populates it will all the versions of the packages I expect to see. However, the content files do not get copied to the appropriate places in the MVC app directory. The weird thing is that it does create directories for the content, but does not copy the content files themselves.
For example, I am using the Twitter Bootstrap package which appears in the packages/Twitter.Bootstrap.2.2.2. In the MVC project a directory called bootstrap (containing css, img, and js directories) gets created in the Content directory. But, no css or js files are copied into those directories!
Does anyone have a clue what magic incantation I must utter to get the build to copy these content files from the NuGet packages directory?
This is a very common issue we are all having. I've created an MSBuild Task NugetContentRestoreTask that will do this trick for you. Run the following command in the Package Manager Console:
Install Nuget Content Restore MSBuild Targets
PM> Install-Package MSBuild.NugetContentRestore
The only thing left is to call it from your BeforeBuild Target with something like this:
Project File Targets
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)" />
</Target>
You can take a look at the source repo and find it on nuget.org
Additional Content Folders
This nuget only includes the default folders scripts, images, fonts, and content, it is not a recursive directory includes. For additional content subfolders - you must assign the property AdditionalFolders.
<Target Name="BeforeBuild">
<NugetContentRestoreTask SolutionDir="$(SolutionDir)" ProjectDir="$(ProjectDir)"
AdditionalFolders="less;sass;common" />
</Target>
I have found a workaround, but it is ugly. By executing the following command in the NuGet Package Manager Console: Update-Package -Reinstall all the files are indeed copied to their proper places within the Mvc project Content and Scripts directories.
Unfortunately, this is risky because you are likely to end up with the wrong versions of certain packages. For example, in my case after the command finishes executing (which takes quite a while by the way), I end up with jQuery version 1.4.4. This is way old, and I assume it must be an explicit dependency of some other package that is being updated. So it appears that the order in which the packages actually get updated by NuGet is significant (it does not appear to parse the entire dependency tree for all packages and pick only the latest versions from the union of all dependencies, which seems like it would be the preferred behavior). Rather, as the command executes I see it replacing the jQuery package several times with different versions as it works its way through all the packages and their dependencies, only to end up with a very old version.
A similar approach is the execute the Update-Package -Reinstall command explicitly for each package that is causing my problem, but this is incredibly tedious and error prone.
The NuGet Package Restore feature should yield the same result as manually executing the Install-Package or Update-Package -Reinstall command for a package, but it does not.
I don't like to have the thirdparty JavaScript files under source control either. Thats why I've followed Jeff Handley advice in http://nuget.codeplex.com/workitem/2094 to create a solution my self. I didn't go the executable way, but created a nuget solution level package which does the trick.
http://www.nuget.org/packages/Baseclass.Contrib.Nuget.GitIgnoreContent/
It's tied to git, as it automatically updates the .gitignore file.
Short description:
Ignore nuget content files in git:
Generate entries in the .gitignore file to exclude nuget content files from the source repository
Restore nuget content files before building (Automatically in VS and manually with a powershell script
I've written a blog post describing how to use it.
http://www.baseclass.ch/blog/Lists/Beitraege/Post.aspx?ID=9&mobile=0
In Visual Studio 2015 Update 1, they now support contentFiles. The caveat with this is that it only works in projects that use project.json.
In reference to the problem that you are having, there is a good blog post that explains why you see this behaviour: NuGet Package Restore Common Misconceptions.
For my projects it turned out that content files work with PackageReferences only:
Existing project with nuget references via packages.config
Installed NuGet package with content files
Build project
No content files in output directory
Conversion of packages.config to PackageReferences
Build project
Content files have been copied to output directory
IDE is Visual Studio 2017. The project is an application project which means it is in the old csproj format.