I am able to read packages from NuGet.org but I am not able to read only certain packages from our private NuGet server - Klondike.
I tracked requests which VS2015 made to download package and query string which VS2015 sends to NuGet source is:
?$filter=IsAbsoluteLatestVersion&searchTerm='Package-ID'&targetFramework='net'&includePrerelease=true&$skip=0&$top=126
Problem is with parameter targetFramework. When VS2015 uses targetFramework='net' than it cannot read packages for framework net461, they are skipped.
When I executed request in Postman and set targetFramework='net461' then I am able to find package.
Also I noticed that VS2015 sporadically changing target framework from net to net461.
My question is: Do I need to configure my VS2015 or I have to change my NuGet package?
NuGet package is created form .NET Core 2.0 project and here is configuration:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netcoreapp2.0;net461</TargetFrameworks>
<Company>Stackoverflow</Company>
<Authors>kat1330</Authors>
<Description>Package consists banch of functionalities.</Description>
<PackageTags>rules, rule engine</PackageTags>
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
<IncludeSymbols>true</IncludeSymbols>
<IncludeSource>True</IncludeSource>
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>..\cert.snk</AssemblyOriginatorKeyFile>
<DelaySign>true</DelaySign>
<VersionPrefix>1.0.0</VersionPrefix>
<VersionSuffix>$(VersionSuffix)</VersionSuffix>
<ApplicationIcon>favicon.ico</ApplicationIcon>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
</ItemGroup>
</Project>
UPDATE: Version of NuGet package manager is: 3.5.0.1484. It is latest what is offered on Visual Studio 2015 for me.
I am able to find packages form nuget.org and "certain packages" from private source. "Certain Packages" means some are visible and some not
Since you able to find packages form nuget.org and "certain packages" from private source ("Certain Packages" means some are visible and some not), so, the reason for the invisible package should be related to the package itself not about the nuget and private source.
According to the sample config for package, I noticed that the value of GeneratePackageOnBuild is set to False rather than True:
<PropertyGroup>
...
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
...
</PropertyGroup>
When the value is set to false, Visual Studio will not generate package. So, you should make sure if the package is generated. If it was generated, check if you can access it and download it.
Hope this helps.
Related
I'm creating an app to automatically update nuget packages in a solution and build it to be sure they are still compatible.
Scenario:
<PackageReference Include="Dapper" Version="1.50.5" />
Clean/Build package with correct package version. It Succeeds.
Then I edit the version in the .csproj with garbage text.
<PackageReference Include="Dapper" Version="dasdasdasdqw3" />
It still succeeds. However it does log the error:
Error occurred while restoring NuGet packages: Invalid restore input. Missing required property 'Name'.
My understanding is that it is using the previous successful version from the \.nuget\packages folder.
Is there a way to have the build fail if the package could not be restored that does not involve deleting it from \.nuget\packages?
Assume that you used a net core project.
First, make sure that you have enabled these two options under Tools-->Options-->Nuget Package Manager-->General:
Actually, when you change the version, vs will detect the change and use the current version and will not used the latest valid package under \.nuget\packages. In my side, it failed.
Right-click on your project Properties-->Unload project-->Edit Project File and then change from 1.50.5 to adadd. And then reload your project, you will find that the project has an invalid nuget version called asda.
It fails build process successfully. You should click Rebuild rather than Build button.
========
If you did not see the nuget package version displayed UI under solution explorer, you could unload the project and then reload your project. And wait for a moment to get the change.
Besides, you could add dotnet restore command under Project Properties-->Build Events-->Pre-Build event command line to make it more accurately.
To use the latest updated version automatically, you could use Floating Versions.
Try this:
<PackageReference Include="Dapper" Version="*" />
It will update the nuget package to use the latest version under nuget package source feed rather than the latest version from cache \.nuget\packages. When you reload your project, wait for a moment, and you will see the change to use the latest nuget version automatically.
Using MSBuild, the following builds and works fine:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<Target Name="Publicise" BeforeTargets="BeforeBuild">
<Publicise
AssemblyPath="..."
OutputPath="../"/>
</Target>
However, when I add another Package Reference (changing nothing else), it encounters errors on build:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<PackageReference Include="ILRepack.MSBuild.Task" Version="2.0.13"/>
This results in error MSB4062:
The "Publicise" task could not be loaded from the assembly ...\ILRepack.MSBuild.Task.dll. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
Why is something completely separate preventing the task from being properly found, and how can I fix this?
The issue is caused by these two msbuild task nuget packages accidentally.
And since you have installed the ILRepack.MSBuild.Task nuget package at the end. And the PackageReference node of ILRepack.MSBuild.Task is akways at the end. So $(TaskAssembly) is always loads from ILRepack.MSBuild.Task nuget package and the value from publicise.msbuild.task is being covered. And the issue The "Publicise" task could not be loaded from the assembly ILRepack.MSBuild.Task.dll makes sense.
C:\Users\xxx\.nuget\packages\publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props
C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props
Also, when you project loads the nuget package, you can check under C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props:
Loading the ILRepack.MSBuild.Task.props is always at the end and $(TaskAssembly) is always from ilrepack.msbuild.task due to being overwritten by the later installed package.
The error Publicise task(should be from publicise.msbuild.task) from ilrepack.msbuild.task could be understood.
Solution
So you should make publicise.msbuild.task at the end.
Solution 1)
open C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props file,
modify like this:
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props')" />
<Import Project="$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props')" />
</ImportGroup>
make Publicise.MSBuild.Task.props at the buttom.
Then, save the changes and then click Build button rather than Rebuild button to test again.
Solution 2)
downgrade ILRepack.MSBuild.Task nuget package to version 2.0.0.
===============================
Update 1
Thanks for sharing your opinion about the workaround. Since these two nuget packages have to be used in your project, so these two solutions might not be very useful.
The error, conflict is caused by the author of the nuget packages and incidentally, you're using the same TaskAssembly property from these two nuget packages at the same time.
TreatAsLocalProperty="TaskAssembly" will not solve the issue. <packages_id>.props files from the nuget packages are still embedded in the project's CSPROj file. Whether the fields are the same as TaskAssembly or will conflict.
The better solution is that you should rename one of the TaskAssembly of the nuget packages to another, which would not cause conflict.
1) Open C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props file:
change TaskAssembly property to another like TaskAssembly_copy:
I am working on an ASP.Net core 2.1 web app project. I have 1 project in my solution and 3 other libraries, it's and advanced architecture (data access layer (DAL), business layer (BL), common layer (CL)), so i need to add references to connect some libraries and project. I have added CL reference to my project and to libraries DAL and BL. Now I have to add reference BL to my project, but when I add I get this type of error:
Version conflict detected fr Microsoft.EntityFrameworkCore/ Install/reference Microsoft.EntityFrameworkCore 2.2.1 directly to project 'WEB' to resolve this issue
When I am trying to install that version it says
Package restore failed. Rolling back package changes for 'WEB'
I can also mention that when I add reference BL to my project, it also includes DAL, and CL itself, (and DAL contains Microsoft.EntityFrameworkCore (2.2.1), can't understand what's the problem, any ideas?
Additional Images of the problem in here.
project.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\CL\CL.csproj" />
</ItemGroup>
</Project>
i have added CL reference as you can see, now i want to add BL reference and get this error
The issue is because you're having local directory path to one of your {projectName}.csproj file
Kindly review your .csproj files by Right clicking project and select Edit {projectName}.scproj
e.g
<Reference Include="Microsoft.EntityFrameworkCore">
<HintPath>..\..\..\..\..\..\..\Program Files\dotnet\sdk\NuGetFallbackFolder\Microsoft.EntityFrameworkCore\2.1.1\lib\netstandard2.0\Microsoft.EntityFrameworkCore.dll</HintPath>
</Reference>
If yes than go to Nuget Package Manager and add your library bu selecting nuget.org as Package Source
after restoring from nuget Package manager csproject file will have following tag Added
to
<PackageReference Include="Microsoft.Extensions.Identity.Stores" Version="2.1.1" />
Here {projectName} is the name of C# project.
Just want to chip in that i had the same issue but with EntityFrameworkCore 3.0 preview. I solved it by simply downgrading all entityframework 3.0(preview) nuget packages to latest stable (2.2).
Hopefully this helps someone aswell, took me hours...
Option 1 check visual studio error window and identify which package is making the conflict .
make sure both packages have save version code
I'm trying to setup a library nuget package for .net core with the dotnet pack command, however, instead of just having a dll included in the nuget package, a content file from another references nuget is added (which makes the nuget file size 9.6MB instead of 59KB).
Is there a way to avoid getting files and content from other nuget packages in a nuget library project?
to reproduce:
Create a .net core library
Add Hl7.Fhir.Specification.STU3 nuget reference
run dotnet pack
The nuspec file in the newly created nuget package, will reveal that the specification.zip file is regarded as content that must be added.
I've tried testing with a custom nuspec file which is basicly a copy from the dotnet output, but without the content reference. The problem I see, is that the nuspec file contains a lot of references which must be maintained somehow.
Peter Wurzinger's suggestion worked for me. It's a shame he posted as a comment, rather than an answer, since he deserves the rep points. Anyway, this is my csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Hl7.Fhir.Specification.STU3" Version="0.96.0" ExcludeAssets="contentFiles" />
</ItemGroup>
</Project>
when I pack, the bin\Debug\test.1.0.0.nuspec file does not contain the specification.zip file elements that exists when I don't use ExcludeAssets.
I cannot get Microsoft.EntityFrameworkCore 2.0 to work with NETStandard.Library 2.0
Error CS0433 The type 'AttributeUsageAttribute' exists in both 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' Contrived.Model.Schema D:\Contrived\Contrived\Framework\Contrived.Model.Schema\Attributes\EntityColumnAttribute.cs
My .csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup Label="Globals">
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<PackageReference Update="NETStandard.Library" Version="2.0.0" />
</ItemGroup>
</Project>
This also happens if i create a new solution and a netstandard 2.0 library then add entityframeworkcore 2.0
Error CS1703 Multiple assemblies with equivalent identity have been imported: 'D:\Users\maksymiuk_a.nuget\packages\netstandard.library\2.0.0\build\netstandard2.0\ref\System.Threading.Tasks.dll' and 'D:\Users\maksymiuk_a.nuget\packages\system.threading.tasks\4.3.0\ref\netstandard1.3\System.Threading.Tasks.dll'. Remove one of the duplicate references. ClassLibrary1 D:\Contrived\Contrived\ClassLibrary1\ClassLibrary1\CSC
Update: Visual Studio 2017 15.3 and the 2.0.0 SDK have been released. Use these versions to get rid of such conflicts.
This appears to be one of the build issues happening when using a mix of preview-tooling and "RTM" packages before all parts have been released.
To get the best support for 2.0.0 at the time of writing, do one of the following:
only use the same preview2 version of the nuget packages, the installed .NET Core SDK and the latest VS 2017 15.3 preview (15.3 Preview 7).
Use the latest VS 2017 15.3 Preview (Preview 7), install the 2.0.0 (not preview2) .NET Core Sdk from the CI build output at https://dotnetcli.blob.core.windows.net/dotnet/Sdk/2.0.0/dotnet-sdk-2.0.0-win-x64.exe (the same build output location is used by microsoft's 2.0.0 docker images)
The reason for this requirement is that the 2.0.0 SDK knows about these conflicts and trims the conflicting references (System.*.dll in this case) out of the projects.
This issue can still happen even with DOT NET Core 2+, and is caused when the packages you reference in your project depend on a different version of the same package, specifically same namespace.
There are 2.5 solutions that I know of:
1) If you control both packages, then update both to make sure they are using the same version of that dependency (or change the namespace of one of the versions of that dependency, like: Your.Thing.v3.Models)
2) If you can find one or both of those packages on an open source site like GitHub, you can download them and update them to use the same version of that dependency (or the namespace thing from option 1, above)
2.5) If you don't control or have access to the source of those packages, and I realize that this isn't really a solution... (hence the .5), then the last option is to stop using one of those packages.
If there's another way, I'd love to know about it.
Probably not the best idea out there, but try to remove the reference to System.Runtime manually by right-click on references and finding it there.
For me it worked to remove the reference to both assemblies and re-add them again.
Expand your project's References in the Solution Explorer --> Right click the faulty assembly -> Remove.
Then right click References -> Add Reference... -> check the boxes of the assemblies you just removed.
Then rebuild.
In my case I have added multiple reference in web.config file.
after removing one of them resolve the issue and working perfectly under local IIS server also