New to using nuget and packages, my csproj file for a project has it looking for the package at
..\..\..\..\Packages\Portable.BouncyCastle.1.8.10\lib\net40\BouncyCastle.Crypto.dll
Which is correct I want the packages there, but when I run the restore nuget, the package is downloaded to
..\..\..\..\tools\
Which is wrong...
If I un-install and re-install the package it then changes my csproj to
..\..\..\..\Tools\Portable.BouncyCastle.1.8.10\lib\net40\BouncyCastle.Crypto.dll
Can anyone help tell me why is this happening? and how I can fix it?
It seems to be project related as its also happening (and only to this one) when built on a server
This is my packages.config for the project for info
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Newtonsoft.Json" version="12.0.2" targetFramework="net452" />
<package id="Portable.BouncyCastle" version="1.8.10" targetFramework="net452" />
<package id="StyleCop.Analyzers" version="1.1.118" targetFramework="net452" developmentDependency="true" />
</packages>
Related
I am new to Sitecore and Glass.Mapper tools. I am working with Visual Studio 2013 and Sitecore 8.1 for a solution I have begun working on (not the author).
Due to other questions I have observed, I will try to demonstrate what my solution now has in it to remove build errors.
My packages.config includes the following:
<package id="Glass.Mapper" version="4.2.1.188" targetFramework="net45" />
<package id="Glass.Mapper.Sc" version="4.2.1.188" targetFramework="net45" />
My nuget.config includes the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSources>
<add key="nuget v2" value="https://www.nuget.org/api/v2" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
I have added these as project references to each of these Dlls from our Packages directory, which also includes the following in a few of the projects:
<package id="Glass.Mapper.Sc.CastleWindsor" version="3.3.0.25" targetFramework="net45" />
<package id="Glass.Mapper.Sc.Core" version="4.2.1.188" targetFramework="net45" />
<package id="Glass.Mapper.Sc.Mvc-5" version="3.3.0.45" targetFramework="net45" />
Solution errors have been reduced from several hundred to ~20, mostly due to this issue, and the Metadata file "..." could not be found errors which appear since dependent projects fail to generate their project Dlls.
We cannot upgrade Nuget in place, and we cannot perform upgrades using Manage Nuget Packages for Solution due to code in place which references deprecated methods in key packages.
If you browse packages on nuget.org with your web browser, you can guess the pattern for viewing a specific version of a package. So, version 4.2.1.188 of GlassMapper will use the URL https://www.nuget.org/packages/Glass.Mapper/4.2.1.188
There, I see a message saying
The owner has unlisted this package. This could mean that the package is deprecated or shouldn't be used anymore.
So the package exists, so existing packages should be able to restore it, but the owner has delisted it to reduce the probability that new projects will start using it. Interestingly the package owner has delisted all versions of the package, suggesting the package is deprecated.
Anyway, as I mentioned, normally the package can still be restored (that's the point of unlisting vs deleting). So my best guess is that the version of NuGet that works with Visual Studio 2013 doesn't support unlisted packages as it's really, really old.
You could download nuget.exe from nuget.org/downloads, restore from the command line and then use Visual Studio. Otherwise you'll probably need to upgrade to a newer version of Visual Studio.
I am building a nuget package from a c# class library project.
The class library itself has files that are marked as build action=content and I can't change this.
I don't want these content files in the nuget package. If I am using an empty files tag, these content files are not included.
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
...
</metadata>
<files />
</package>
However, if I add at least on other file to my package like this
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
...
</metadata>
<files>
<file src="source/path.dll" target="lib\net45\" />
</files>
</package>
every file marked as content in my project is included in my package, too.
Is there a way to avoid this?
Put this to the end of the .csproj file:
<ItemGroup>
<Content Update="#(Content)" Pack="false" />
</ItemGroup>
This will make every "build action=content" get excluded from the nuget.
Those "build action=content" entries will be actually <Content> Items in the MsBuild project - you could see them in the old .csproj format. (In the new SDK style format, by default, the project files are automatically included based on file extension; so probably you won't see the <Content> entries).
The code above updates every <Content> entry - which already exist when reaching that code (thus it should be at the end of the .csproj) - to be excluded from nuget pack
Using the new build system in TFS2015/VSTS, my SpecFlow tests aren't getting picked up. Within the same project, classes and methods decorated with [TestClass] and [TestMethod], respectively, are picked up and tested by TFS. What are the basic requirements for TFS2015/VSTS to run a SpecFlow 2.0 test?
EDIT: Adding packages.config contents. As you can see, I have SpecRun installed, and from within Visual Studio, I'm able to run SpecFlow tests as I'd expect (i.e. they all appear in Test Explorer)
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="NUnit" version="3.0.1" targetFramework="net452" />
<package id="SpecFlow" version="2.0.0" targetFramework="net452" />
<package id="SpecRun.Runner" version="1.3.0" targetFramework="net452" />
<package id="SpecRun.SpecFlow" version="1.3.0" targetFramework="net452" />
</packages>
Edit you VS Test Task and set the Path to Custom Test Adapters` to where in Source Control your "packages" folder lives.
For example:
$(Build.SourcesDirectory)\packages
Already looked at this answer? Built tests are not added to the Visual Studio Test Explorer window
Close all Visual Studio instances
Go to %TEMP%\VisualStudioTestExplorerExtensions\
Delete all the folders in here
Try again
This helped me out this morning (VS2017, SpecFlow Version:2.1.0.0, SpecFlow+ Excel Version:1.4.2.0).
I have C# project that has to target .NET 3.5. framework and I have several nuget packages I'd like to install in the given project.
How to find out, for a given nuget package, which .NET framework versions it supports (by version of package for example), without me trying to install every available version of the package in order to see if its installation will pass without rolling back because of the dependency of the given version of the package to .NET framework higher than 3.5.?
For example, I know that xUnit.net version 1.9.2. is the highest version that supports .NET 3.5, but I had to find out this "manually".
Cannot comment on the previous answer, but the targetFramework attribute in packages.config is the .NET version of the project at the time that package was installed.
For example, I have two projects that use Newtonsoft.Json 9.0.1, and these are the lines in their respective packages.config files:
<package id="Newtonsoft.Json" version="9.0.1" targetFramework="net452" />
and
<package id="Newtonsoft.Json" version="9.0.1" targetFramework="net462" />
packages.config should give you the version info
example
<package id="xunit" version="2.2.0-beta1-build3239" targetFramework="net46" />
<package id="xunit.abstractions" version="2.0.0" targetFramework="net46" />
<package id="xunit.assert" version="2.2.0-beta1-build3239" targetFramework="net46" />
<package id="xunit.core" version="2.2.0-beta1-build3239" targetFramework="net46" />
<package id="xunit.extensibility.core" version="2.2.0-beta1-build3239" targetFramework="net46" />
<package id="xunit.extensibility.execution" version="2.2.0-beta1-build3239" targetFramework="net46" />
<package id="xunit.runner.msbuild" version="2.2.0-beta1-build3239" targetFramework="net46" developmentDependency="true" />
<package id="xunit.runner.visualstudio" version="2.2.0-beta1-build1144" targetFramework="net46" developmentDependency="true" />
At the risk of upsetting the Stack admins for daring to submit a wrong answer...
You can download the .nupkg file (https://www.nuget.org/packages > Download ) then unzip it. In the file you can find references to PlatformToolset, ToolsVersion which I was able to use to look up the specific version of the compiler. ("v110" = Visual C++ 2012, "v120" = Visual C++ 2013, etc. To get the framework you could use decompiler a tool like ILSpy to inspect included files to see what version they target.
As of June 2022 there's at last the possibility to see which .NET Framework/Standard version is supported by a package.
Unfortunately it's only on the website and does not work in Visual Studio. Nevertheless it's very practical.
Here's how it looks for Newtonsoft.Json 13.0.2:
This is far from what I deemed as necessary, but it's a beginning (after 6 years of waiting).
Recently my build on AppHarbor was broked with following message:
The build restored NuGet packages. Build the project again to include these packages in the build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568.
I have next changes related to NuGet (in packages config):
from
<package id="Microsoft.Bcl.Build" version="1.0.8" targetFramework="net45" />
<package id="Microsoft.Net.Http" version="2.1.10" targetFramework="net45" />
to
<package id="Microsoft.Bcl.Build" version="1.0.10" targetFramework="net45" />
<package id="Microsoft.Net.Http" version="2.2.13" targetFramework="net45" />
+
<package id="DotNetOpenAuth.Core" version="4.1.4.12333" targetFramework="net45" />
I have reinstalled to old versions Bcl and Net packages,but this doesnt help me.Has anybody the same problem?Thanks.
This Microsoft blog post has additional details. Apparently, checking in your .targets file addresses the problem.