When I run nuget.exe pack for a project, I get the following error:
EXEC : warning : 1 issue(s) found with package 'Company.LibName'.
Issue: Specify version of dependencies.
Description: The version of dependency 'Newtonsoft.Json' is not specified.
Solution: Specifiy the version of dependency and rebuild your package.
(Specify typo is actually in the message.)
The offending line in the .nuspec file is the last line below:
<dependencies>
<group targetFramework="net45">
<dependency id="Newtonsoft.Json" />
However, I don't want specify a version. And I didn't think I needed to, see documentation:
https://docs.nuget.org/create/nuspec-reference#specifying-dependencies-in-version-2.0-and-above
What's the deal?
I think its just a warning and to be ignored.
It seems it only warns for one package, so although it appears to have singled-out Newtonsoft.Json as needing a version, if I reorder the dependencies, it's always the first one in the list (without a version) that invokes the warning.
Related
I built my private Nuget repository on Azure free app service.
And I added the url into Visual Studio 2015.
There is a package having three versions 1.0.3~1.0.5.
The problem is only 1.0.3 version of the package will be successfully installed.
Others are always failed due to the exception (Too long path or file name).
I don't know why they show me different results.
Non of settings are different.
Also I placed the project folder on the root of D: drive.
Please see the log and let me know the reason :D
Attempting to gather dependency information for package 'GEPAEntities.1.0.5' with respect to project 'TestApps\EntitiesTestConsole', targeting '.NETFramework,Version=v4.0'
Gathering dependency information took 52.53 ms
Attempting to resolve dependencies for package 'GEPAEntities.1.0.5' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'GEPAEntities.1.0.5'
Resolved actions to install package 'GEPAEntities.1.0.5'
Retrieving package 'GEPAEntities 1.0.5' from 'P-ful, Inc.'.
GET http://pfulnugetserver.azurewebsites.net/api/v2/package/gepaentities/1.0.5
OK http://pfulnugetserver.azurewebsites.net/api/v2/package/gepaentities/1.0.5 63ms
Installing GEPAEntities 1.0.5.
Error downloading 'GEPAEntities.1.0.5' from 'http://pfulnugetserver.azurewebsites.net/api/v2/package/gepaentities/1.0.5'.
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
Install failed. Rolling back...
Package 'GEPAEntities.1.0.5' does not exist in project 'EntitiesTestConsole'
Package 'GEPAEntities.1.0.5' does not exist in folder 'D:\GEPAClient\packages'
Executing nuget actions took 803.27 ms
Error downloading 'GEPAEntities.1.0.5' from 'http://pfulnugetserver.azurewebsites.net/api/v2/package/gepaentities/1.0.5'.
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
========== Finished ==========
Time Elapsed: 00:00:03.2133955
I am not sure, but I resolved my problem.
I just added supported framework versions into nuspec file.
<dependencies>
<group targetFramework=".NETFramework4.5" >
...
</group>
<group targetFramework=".NETFramework4.0" >
...
</group>
</dependencies>
Anyway it is working that I expected.
I Nugot SpreadsheetLight. To subsequently use it, I need to add the following usings:
using DocumentFormat.OpenXml;
using DocumentFormat.OpenXml.Spreadsheet;
using SpreadsheetLight;
For the first two ("DocumentFormat") to be recognized, I needed to also NuGet Microsoft's "Open XML Format SDK"
I got the latest version of that, 2.5
However, even then, I got an err msg about needing a reference to it:
The type 'DocumentFormat.OpenXml.Spreadsheet.InlineString' is defined in an assembly that is not referenced. You must add a reference to assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
This line of SpreadsheetLight code provoked that msg:
sl.SetCellValue("A1", true); // "sl" is an SLDocument
So, I removed the reference that I had NuGot (version 2.6.0.0, Runtime Version v4.0.30319) from my project, and then added back the reference by browsing to C:\Program Files(x86)\Open XML SDK\V2.0\lib and selecting "DocumentFormat.OpenXml.dll"
I then got a compiler Warning:
Found conflicts between different versions of the same dependent assembly. Please set the "AutoGenerateBindingRedirects" property to true in the project file. For more information, see http://go.microsoft.com/fwlink/?LinkId=294190.
I noticed that the DLL I added from the file system was version 2.5.5631.0, and the one that had been NuGot and installed as a reference that way was version 2.6.0.0 The Runtime Version was different, too (v4.0.30319 was installed by NuGetting "Open XML Format SDK", but the version of the DLL I manually added is 2.5.5631.0, Runtime Version v4.0.30319
According to this, I gathered that I should edit the .csproj file by changing <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects> to true - but AutoGenerateBindingRedirects does not exist there.
I don't know whether I should add it, and if so (in which "block"). I prefer to play it safe and assuage the Warning engine. How can I ensure that the OpenXml assembly doesn't cause a conflict?
Assuaging that Warning (so that it rides off into the sunset) is a matter of downgrading the version of DocumentFormat.OpenXML to Version 2.0.5022.0 (Runtime Version v2.0.50727)
I found this out because this code from the "Hello World" example here.
SLDocument sl = new SLDocument();
sl.SetCellValue("A1", true);
. . .
...failed on the first line with, "Could not load file or assembly 'DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies"
And so, since it's expecting version 2.0, I removed my 2.5.5631.0 of that file and then NuGot "OpenXML SDK 2.0" in its stead. That is Version 2.0.5022.0 and Runtime Version v2.0.50727
So: No need to update the project file with an arcane boolean property after all.
It kind of gives me the fantods, though, to have to use an older version of an assembly.
UPDATE
The need to "go retro" with DocumentFormat.OpenXml is corroborated here.
One can solve the problem by redirection of DocumentFormat.OpenXml from Version 2.0.5022.0 to more recent version, for example to version 2.5.5631.0. To do this one should add in web.config the new <dependentAssembly> item:
<configuration>
...
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
...
<dependentAssembly>
<assemblyIdentity name="DocumentFormat.OpenXml" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="1.0.0.0-2.0.5022.0" newVersion="2.5.5631.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
...
<configuration>
Spreadsheetlight works with DocumentFormat.OpenXml 2.5 since version 3.4.5:
"Version 3.4.5
- SmartTags is now removed from consideration (not so smart now, are you? ;). Which means the code is now ready for Open XML SDK 2.5! And yes, it now works with Open XML SDK 2.5 (have I mentioned that? lol)"
quote from: https://www.nuget.org/packages/SpreadsheetLight/
I am currently trying to publish a load of nuget packages for all the projects in this solution. The projects are setup in a simple tree, with Myre being the base project and everything depending on it:
Myre <- Myre.Debugging <- Myre.Debugging.UI <- Myre.UI
Myre <- Myre.UI
Myre <- Myre.Entities <- Myre.Graphics
I'm trying to package up each separate project as a nuget package with the correct dependencies on the other Myre subproject packages as necessary.
My first step was to make a package for Myre (nuspec and bat file of process). This seems to work nicely, the gallery shows Myre as having a ninject (another nuget package) dependency and all is well.
The problem comes when I tried to make the next package. Myre.Debugging depends upon Myre (with a normal project reference) and nothing else. Using this nuspec with nuget pack (verbose) gives:
Attempting to build package from '(x86) Myre.Debugging.csproj'.
Packing files from 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release'.
Add file 'C:\Long_Path\Myre\Myre.Debugging\bin\x86\Release\Myre.Debugging.dll' to package as 'lib\net40-Client\Myre.Debugging.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.dll' to package as 'lib\net40-Client\Myre.dll'
Add file 'C:\Long_Path\Myre\Myre\bin\x86\Release\Myre.XML' to package as 'lib\net40-Client\Myre.XML'
Found packages.config. Using packages listed as dependencies
Id: Myre.Debugging
Version: 1.0.0.2
Authors: Microsoft
Description: Description
Dependencies: Ninject (= 3.0.1.10)
Added file 'lib\net40-Client\Myre.Debugging.dll'.
Added file 'lib\net40-Client\Myre.dll'.
Added file 'lib\net40-Client\Myre.XML'.
Successfully created package 'C:\Long_Path\Myre\Myre.Debugging\Myre.Debugging.1.0.0.2.nupkg'.
As you can see it picks up a packages.config file (presumably from Myre since there isn't one here) which it then determines a Ninject dependency from. If I wanted Myre.Debugging and Myre to be a single package that would be fine. However this is not what I want, I want Myre.Debugging to pick up a dependency on the Myre package.
How can I setup nuget to use Myre as a package reference and not simply to copy the Myre assemblies into the Myre.Debugging package?
Edit:: I tried not using -IncludeReferencedProjects and specifying:
<dependencies>
<dependency id="Myre" version="1.0.0.1" />
</dependencies>
But for some reason this just creates a package with no dependencies at all! Even if manually specifying dependencies like this did work, it's hardly ideal.
According to the NuGet command line reference for the Pack command, the IncludeReferencedProjects switch works as follows:
Include referenced projects either as dependencies or as part of the package. If a referenced project has a corresponding nuspec file that has the same name as the project, then that referenced project is added as a dependency. Otherwise, the referenced project is added as part of the package.
In your case, Myre.Debugging.nuspec does not match the project file names: (x86) Myre.Debugging.csproj, etc. I suspect that you'll need to match up those file names to get that command line option to work.
Alternatively, if you want to get this to work with a <dependencies> element in your nuspec file, you may be facing another variant on the name mismatch problem. Your Myre.nuspec file defines its ID as follows:
<id>$id$</id>
The NuSpec reference says that the $id$ token is replaced by "The Assembly name." If it's talking about the name of the DLL (ignoring the extension), then I think the generated IDs will be (x86) Myre, etc. You might want to try hard-coding the ID temporarily just to see if that resolves the issue.
I haven't tried making these suggested changes, and I can't guarantee they will work, but I hope this points you in the right direction. Good luck!
I'm going to bang out a couple of questions here...first, with NuGet is it possible to create a package from a few DLLs? There is no visual studio project, just the command line and a couple of pre-compiled DLL files.
Second, assuming that is possible, why do I continuously get the "Assembly outside of the lib folder" warning? I've tried everything I can think of to get associated assemblies to add themselves as references inside of the NuGet package.
My file structure looks like this
Root
- File1.dll
- lib
- File2.dll
- File3.dll
When I tell NuGet to pack it using a .nuspec like this
<?xml version="1.0"?>
<package >
<metadata>
<id>File1.dll</id>
<version>1.0.0</version>
<authors>thisguy</authors>
<owners>thisguysmom</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>This is some library</description>
<releaseNotes>Porting to NuGet</releaseNotes>
<copyright>Copyright 2012</copyright>
<references>
<reference file="File2.dll" />
<reference file="File3.dll" />
</references>
</metadata>
</package>
I receive that warning. From what I'm reading, I shouldn't even have to define the references node in any of my projects, as the lib folder items should automatically be added as references?
Does anyone out there understand this NuGet mess?
I just ran into this problem. Nuget is expecting a structure that looks like:
root
- lib
- net40
- File1.dll
- File2.dll
- File3.dll
net40 or net20 or net45 as appropriate to your .net version.
run
nuget pack yourlibrary.nuspec
to package it up.
That will pack up the dir wholesale and put it in the nupkg. The error messages will disappear at that point.
Any dll that you want referenced should be under the lib folder. The warning is because file1.dll is outside lib and will be ignored during package installation. (Other special folder are "content" and "tools")
I'd used this structure :
Root
- lib
- File1.dll
- File2.dll
- File3.dll
See : http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package#Package_Conventions for additional details.
With the version of NuGet that is current as of this post (and I assume later versions as well), you can use the .csproj file, in tandem with the .nuspec file to create the package. What we did was make a .nuspec file (using nuget spec and then customizing it) and include it in the project.
With the customized .nuspec file, we used the command:
nuget pack sample.csproj -IncludeReferencedProjects
At that point it built the .nupkg and did not emit issues. The .nupkg file showed up in the normal output folder (in my default case, bin\debug).
You may add references to another dll by adding below inside tag in nuspec file
<package>
<metadata>
...
</metadata>
<files>
<file src="..\ReferencedFolder\*.*" target="lib\net40\" />
</files>
</package>
Alexandre is referring to the "lib" folder that gets created when you create a NuGet package. You can open the .nupkg just like you would any zip file. In there, you will see a lib\netXX folder where XX is the version of the .NET framework you're targeting. So when you're packing your NuGet file, make sure File1.dll is inside the lib folder.
I used Prof Von Lemongargle' solution, and for me was a great solution.
Important:
Include spec file (with right-click-> Include in project) in the project
Give to spec file THE SAME FILENAME of your project (myproject.csproj, myproject.nuspec)
This work perfectly in Visual Studio 2012.
They get into the "lib" folder by being included in your bin\debug or bin\release folder in .NET. So you need to get the project compile to copy local on the external DLLs so it includes them in the bin folder on compile.
If dependencies or libraries have been changed, old files affect the packaging operation.
Remove obj and bin folders from project.
Run dotnet restore
Run nuget pack yournuspecfile.nuspec -properties Configuration=Release -IncludeReferencedProjects or your command whatever.
Is it possible to Deploy PostSharp into a Source Repository in conjunction with NuGet Package Restore?
I can get this working by committing the postsharp package, but that negates somewhat the value of the Package Restore feature.
Here’s what I did.
I was trying to set up postshap like so: Deploying post sharp into a source repo
I have set up nugget to use without commiting like so: Using NuGet Without Committing Packages to Source Control
I see this in my csproj
<Import Project="..\packages\PostSharp.2.1.6.13\tools\PostSharp.targets" />
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
(I re-ordered them to no avail)
And my build server (CC.net) reports the following errors:
D:\wwwroot\www.snip.co.nz\http\www.snip.co.nz.csproj (714,3):
errorMSB4019: The imported project "D:\wwwroot\www.snip.co.nz\packages\PostSharp.2.1.6.13\tools\PostSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
CacheAttribute.cs (8,7):
errorCS0246: The type or namespace name 'PostSharp' could not be found (are you missing a using directive or an assembly reference?)
…etc…
You currently (v2.1.6.13) have to fix the csproj to support Package Restore,
within the Import target element add the condition shown here:
<Import Project="..\packages\PostSharp.2.1.6.13\tools\PostSharp.targets"
Condition="Exists('..\packages\PostSharp.2.1.6.13\tools\PostSharp.targets')" />