I tried adding some standard nugets to my .Net standard 2.0 library project. But when compiling I get the following type of errors:
The type 'IDisposable' 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'
and
Predefined type 'System.Object' is not defined or imported
Here is my project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="System.Net.WebSockets" Version="4.3.0" />
<PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.7.0" />
</ItemGroup>
</Project>
Both nugets declare support for .Net Standard. I used VS 15.3 preview 2.
Is there some magic setting for .Net Standard 2.0 libraries I need to be aware of? What do I need to do to get a .Net standard 2.0 library compiling?
This happens due to a bug in the conflict resolution targets / infrastructure that is fixed in current 2.0.0-preview2 builds. These aren't included in VS 2017 15.3 preview 2.0 and need to be installed separately (e.g. from the links in https://github.com/dotnet/cli/tree/release/2.0.0).
Note that VS 2017 15.3 now uses an "SDK resolver" that looks for a global.json in the opened project and uses the SDK version it resolves to (or latest) instead of the bundled SDKs.
Related
I have a project targeting NET 6.0 framework.
When I build the project, I’m getting this message
Warning
Detected .NET Core SDK 7.0.100. This SDK version was not tested on this version of PostSharp. Using it may result in a build failure. Supported SDK versions are 2.1.500 to 6.0 (any revision).
Here is my project file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<AssemblyName>$(MSBuildProjectName)</AssemblyName>
<RootNamespace>$(MSBuildProjectName.Replace(" ", "_"))</RootNamespace>
<LangVersion>9.0</LangVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
<PackageReference Include="PostSharp.Patterns.Model" Version="6.10.16" />
<PackageReference Include="System.ComponentModel.Annotations" Version="5.0.0">
<TreatAsUsed>true</TreatAsUsed>
</PackageReference>
</ItemGroup>
</Project>
Building project in visual studio 2022
You can update PostSharp to version 2023.0.3. It supports .NET 7 SDK.
The fact that your project targets .NET 6 doesn't imply that .NET 6 SDK is going to be used to build your project. By default, the highest installed SDK is used, unless you configure otherwise using global.json configuration file.
Trying to reference Windows.Devices.Geolocation to use the Geolocator class from a .NET 6 core WinUI desktop head. I suspect - I am not sure - maybe the NetStandard flavor of Uno.dll intending to load here and that is why FileNotFoundException ?
FileNotFoundException: Could not load file or assembly 'Uno, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
<PackageReference Include="Uno.WinUI" Version="4.2.6" />
Perhaps a little bit of WinDBG helps anything ? For me nothing.
What is more, it is not just a run time issue, even Visual Studio can't locate the assembly in source :
Procmon reveils, the assembly is found in the right nuget folder but the respective application process log not found:
I made a PR to your GitHub repro, but the steps needed were as follows.
First, the library had to be switched to multi-targeted by changing to <TargetFrameworks> in the .csproj:
<PropertyGroup>
<TargetFrameworks>net6.0;net6.0-windows10.0.19041.0</TargetFrameworks>
</PropertyGroup>
Now the net6.0 target is for all Uno targets and the net6.0-windows10.0.19041.0 is specifically for WinAppSDK on Windows desktop.
Secondly, the Uno.WinUI needs to be referenced only on Uno targets, so:
<ItemGroup Condition="'$(TargetFramework)' != 'net6.0-windows10.0.19041.0'">
<PackageReference Include="Uno.WinUI" Version="4.2.6" />
</ItemGroup>
After these changes, the Windows project will no longer try to access the Geolocator type from Uno.dll and will use the proper Windows SDK Geolocator:
Problem: Top level project references MyLibrary nuget which references several vendor.dll files. Vendor.dll files should be able to be referenced by top level project when MyLibrary nuget package is added to top level project but they are not.
When I run the top level project I receive this error:
FileNotFoundException: Could not load file or assembly 'Vendor.A, Culture=neutral, PublicKeyToken=b88d1754d700e49a'. The system cannot find the file specified.
Vendor .dll files are not copied to bin folder.
I hope to find a resolution to this problem that does not require me to create a .nuspec file.
Structure of generated MyLibrary nuget package (observed with Nuget package explorer):
lib
net5.0-windows
Vendor.a.dll
Vendor.b.dll
net5.0-windows7.0
MyLibrary.dll
I do not understand where net5.0-windows7.0 comes from. It does not exist in TFM list referenced below. Also, if net5.0-windows7.0 is for some reason necessary, why does MyLibrary.dll exist there but not the .dlls it depends on?
Looking at the package from within Visual Studio 2019 it appears as follows (vendor dlls do not appear):
Packages
MyLibrary
Compile Time Assemblies
MyLibrary.dll
MyLibrary.csproj:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
<PropertyGroup>
<AssemblyVersion>1.0.0.1</AssemblyVersion>
<FileVersion>1.0.0.1</FileVersion>
<Version>1.0.0.3</Version>
</PropertyGroup>
<ItemGroup>
<Content Include="$(OutputPath)\Vendor.*.dll">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)</PackagePath>
</Content>
</ItemGroup>
<ItemGroup>
<Reference Include="Vendor.a">
<HintPath>VendorLib\Vendor.a.dll</HintPath>
</Reference>
<Reference Include="Vendor.b">
<HintPath>VendorLib\Vendor.b.dll</HintPath>
</Reference>
</ItemGroup>
TopLevel.csproj
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MyLibrary" Version="1.0.0.3" />
</ItemGroup>
Target Framework Monikers
Similar question
Similar question requiring nuspec
Similar question requiring nuspec
Possibly related issue
I also found an issue about this strange behavior and still did not know where the net5.0-windows7.0 from. Since the issue is still open and the Team does not know it is normal or a strange issue, as my opinion, net5.0-windows7.0 is the special version for wpf project's frameowork of nuget, so you should pack your dlls into such folder of nupkg.
Although this is not the best function, but is a workaround now. You can keep tracking the issue to get the explanation from the Product Team.
Or try my suggestions:
function one
1) change the targetframwork of your nuget project to
<TargetFramework>net5.0-windows7.0</TargetFramework>
As the Team said, net5.0-windows is the same as net5.0-windows7.0. However, they treat them differently in terms of packaging into nuget.
function two
2) still use <TargetFramework>net5.0-windows</TargetFramework>.
change this to:
<ItemGroup>
<Content Include="$(OutputPath)\Vendor.*.dll">
<Pack>true</Pack>
<PackagePath>lib\$(TargetFramework)7.0</PackagePath>
</Content>
</ItemGroup>
Besides, when you finish packing nuget project, please delete nuget caches first or delete all files under C:\Users\xxx\.nuget\packages, then install the new release version of the nuget package into the main project.
vendor is my custom nuget project name.
I migrated an ASP.NET Core project from .NET Framework to .NET Core and in the process replaced the AspNetCore nuget packages with the Microsoft.AspNetCore.App metapackage. Originally I specified a version for it which worked fine, but VS whined about that telling me I'm not supposed to specify a version, so I removed it. Once I did that this happened:
'Microsoft.AspNetCore.Mvc.ViewFeatures, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version than referenced assembly 'Microsoft.AspNetCore.Mvc.ViewFeatures' with identity 'Microsoft.AspNetCore.Mvc.ViewFeatures, Version=2.0.0.0,
These are coming from a Unit Test project which references my ASP.NET Core project. The ASP.NET Core project builds fine on its own. Now, I understand what this error means - somewhere in this Test project I must be referencing this package with a different version than what is provided by the metapackage. What I want to know is where is this package being referenced in my Test project? I have the following nuget packages in the Test project:
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="2.2.4" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
<PackageReference Include="Moq" Version="4.10.1" />
<PackageReference Include="MSTest.TestAdapter" Version="1.3.2" />
<PackageReference Include="MSTest.TestFramework" Version="1.3.2" />
</ItemGroup>
I don't see where any of these packages use any AspNetCore dependencies, so I'm at a loss as to where the version mismatch could be.
In some of my csproj files I have this but some dont:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
What exactly is this and why do I need it? My other projects are restoring their packages just fine without it.
I am using VS2013 and NuGet 2.8.
It ensures that the imported .props and .targets files are indeed imported. NuGet has supported NuGet MSBuild support since 2.5. EnsureNuGetPackageBuildImports code was added in September, but I think it is a 2.8 change. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 who will now need to upgrade to 2.8. I found EnsureNuGetPackageBuildImports in Common/MsBuildProjectUtility.cs on line 11.