I'm not so sure why this can be a problem, I've just revised some documentation about SignalR in ASP.NET Core and it seems to mean that I don't have to install any additional package (already have Microsoft.AspNetCore.All and Microsoft.AspNetCore.App referenced after creating a new ASP.NET Core project (version 2.2).
I've even tried Googling and found this blog post: https://wakeupandcode.com/real-time-asp-net-core-web-apps-with-signalr/#dep
It was written on Dec 23 2018, and the author does confirm that we don't need to install any additional package.
Well so it's really playing on me, making me have a feeling of being stupid, not so sure why I cannot use SignalR in my project (I'm not intending to install any additional package, which I think should work for me), just wonder why it's not already available. The following code does not compile:
using Microsoft.AspNetCore.SignalR;
It reports that SignalR does not exist in the namespace Microsoft.AspNetCore right in the project that has Microsoft.AspNetCore.All and Microsoft.AspNetCore.App.
Actually I cannot find the Microsoft.AspNetCore.SignalR when expanding the references tree.
The documentation says nothing about where to import the module (which means it should already be available). As I said the project targets .NET Core 2.2. Could you explain to me something could be wrong here?
PS: My project is a Web API (not MVC) project.
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Autofac" Version="4.9.4" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.9" />
<PackageReference Include="Microsoft.Extensions.Hosting" Version="2.2.0" />
</ItemGroup>
Usually, project templates have outdated libraries. Use the NuGet package manager to update references to recent versions and try again. It should help.
I want to understand why Microsoft recommends not to specify an explicit version for Meta Package.
I am new to dot net core and I am trying to understand the importance of implicit versioning with respect to Meta Packages in web.config file.
I also went through github discussion about the implicit version. But I didn't understand much.
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" />
</ItemGroup>
</Project>
I wanted to know what are the disadvantages of mentioning version explicitly in the above code?
In MSBuild there is a variable $(BuildingInsideVisualStudio) which can be used to detect whether build is running inside Visual Studio, so I can do conditions like this:
<PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != 'true'">
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>
Is there anything similar for NuGet? I want different conditions to run if the project is being used inside package manager.
Your comment to the question makes it sound like your goal is to keep a packages versions consistent across different conditions in a single project, but it's also a common case that you want to keep it consistent across projects in a solution or repo.
I'm going to suggest a different solution. Create a Directory.Build.props in your repo root that looks something like this:
<Project>
<PropertyGroup>
<NewtonsoftJsonVersion>12.0.1</NewtonsoftJsonVersion>
<xunitVersion>2.4.1</xunitVersion>
</PropertyGroup>
</Project>
Now in your projects that need Newtonsoft.json, you change the PackageReference to <PackageReference Include="Newtonsoft.Json" Version="$(NewtonsoftJsonVersion)" />.
If you put your production code in src\ and test code in test\, then you can create a test\Directory.Build.props with the contents:
<Project>
<Import Project="$([MSBuild]::GetPathOfFileAbove('Directory.Build.props', '$(MSBuildThisFileDirectory)../'))" />
<PropertyGroup>
<PackageReference Include="xunit" Version="$(xunitVersion)" />
</PropertyGroup>
</Project>
Now all of your projects under test\ will get xunit automatically, and it's guaranteed to be the same version.
When you want to upgrade a package version, you can use the Package Manager UI to check for versions, but unfortunately not to upgrade the version. For that, you'll need to manually edit the repo root Directory.Build.props (so add it to your solution for quick access), but you can be confident that every reference to that package will use the same version. It is limited to projects using PackageReference, there's no solution currently for packages.config, but MSBuild conditions only for for PackageReference too.
You can see this pattern often in Microsoft repositories. Certainly NuGet (my team, yay!), and various .NET repos like cli and sdk do it, although in manually imported props files, rather than Directory.Build.props, though the concept is the same.
There is no direct solution for the case. NuGet is just download manager, it loads sources. MSBuild is a build system, it builds sources. They don't exchange any information between.
I would suggest you to move an another way. You can add a props file into your nuget packaging project with
<?xml version="1.0" encoding="utf-8" ?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<ItemGroup>
<PackageUsedFromNuget>true</PackageUsedFromNuget>
</ItemGroup>
</Project>
I am trying to learn and understand nuget and msbuild in .NET Core by examining and manually editing project files (.csproj in .NET Core 2.2).
So when I create WebApi project, the .csproj file looks like this:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
</ItemGroup>
</Project>
Notice that there is no Version attribute specified for the first PackageReference.
Now if I specify it to be the latest stable version 2.2.3 like this:
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.3" />
I get build warning NETSDK1071 which says:
A PackageReference to 'Microsoft.AspNetCore.App' specified a Version
of 2.2.3. Specifying the version of this package is not recommended.
For more information, see https://aka.ms/sdkimplicitrefs
This warning is not shown when Version attribute is omitted so I was wondering how is nuget package Version resolved when not set explicitly?
Also, how does dotnet build knows which version of a nuget package is recommended with the current project settings?
From the link in the warning, you can learn that it is not a regular package, but Meta-package.
It's mean that this package depends on your TargetFramework, and this is mean that when you target to a specific framework that installed in your machine (as SDK), the package will be taken from the specific SDK.
I've created a sample project using dotnet, but I get the following error when building the project:
error : The project was restored using Microsoft.NETCore.App version 2.1.0-rc1, but with current settings, version 2.1.0-preview3-26411-06 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore.
What's the problem? I'm using Visual Studio 2017 build 15.7.0.
I had a similar error message:
The project was restored using Microsoft.NETCore.App version 2.0.7, but with current settings, version 2.0.0 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore
I added the RuntimeFrameworkVersion setting to the .csproj file, and it fixed an issue for me:
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<RuntimeFrameworkVersion>2.0.7</RuntimeFrameworkVersion><!--here is the fix-->
</PropertyGroup>
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.0.7" />
</ItemGroup>
It seems Visual Studio is using different .NET Core versions for restore/build/publish.
To resolve this issue, you could add TargetLatestRuntimePatch attribute in the .csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
</PropertyGroup>
For details, please see this page.
In my case, in the .csproj file I changed
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.0.5" />
</ItemGroup>
to:
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.1.0" />
</ItemGroup>
And it worked.
I’ve installed .NET SDK 2.2.0 and found out that this isn't the correct version and the correct one was renamed to 2.1.300 to be in sync with the .NET Core application whose the last version is 2.1.0. I installed 2.1.300 and everything runs correctly.
Just because you have the latest SDK installed doesn't mean you have the latest runtime installed. I'll never quite understand that.
Run dotnet --info.
I got the following (only the latest installed versions are shown here).
.NET Core SDKs installed:
2.1.300 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:d\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
So I installed 2.1.1 runtime, and now dotnet --info gives me 2.1.1 as well.
Oh and 2.1.3 actually is 2.1.1, but they had to increment it for some reason I don't fully understand about or care about.
I restarted Visual Studio, because it never seems to be able to keep versions in sync
I added the following to PropertyGroup in my .csproj file (unload project + edit)
netcoreapp2.1
2.1.1
Now I thought we didn't need to specify this this any more, and this .csproj file was just created brand new today and it didn't have a runtime version at all. Whatever we're supposed to be doing, this worked for me. I also found this massive thread about versioning with 2.1.1 which I skimmed over, but it seems there are complications with point releases right now, so maybe this specific version is necessary.
I ended up here because of this error:
error : The project was restored using Microsoft.NETCore.App version
2.1.1, but with current settings, version 2.1.0 would be used instead. To resolve this issue, make sure the same settings are used for
restore and for subsequent operations such as build or publish.
Typically this issue can occur if the RuntimeIdentifier property is
set during build or publish but not during restore.
Adding RuntimeFrameworkVersion was the specific fix for that that worked.
Unfortunately there isn't any linked article for this error message, which would be helpful.
Use:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<UserSecretsId>aspnet-...............245435</UserSecretsId>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
<RuntimeIdentifier>win10-x64</RuntimeIdentifier>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.1" PrivateAssets="All" />
</ItemGroup>
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.1.1" />
</ItemGroup>
</Project>
In my case the issue was fixed by ensuring I had two projects, with one depending on the other.
One project had a RuntimeIdentifier specified in the .csproj file, but the other did not. Once I ensured both had matching RuntimeIdentifiers, the problem was fixed.
The specific error I was getting was
error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.0.5, but with current settings, version 2.1.1 would be used instead.
I had
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.0.5" />
</ItemGroup>```
further down the file. Once I removed this and did a clean, the project built successfully.
I have a somehow different solution, working for ASP.NET 2.1, as I had problems with both building and publishing processes:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.0</RuntimeFrameworkVersion> --> fix publishing issues
<PlatformTarget>AnyCPU</PlatformTarget> --> fix publishing issues
</PropertyGroup>
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.1.0" /> --> fix building issues
<ProjectReference Include="..\PublicSonar.Monitor.Persistent.Json\PublicSonar.Monitor.Persistent.Json.csproj" />
</ItemGroup>
</Project>
I experienced the same:
The project was restored using Microsoft.NETCore.App version 2.1.2, but with current settings, version 2.1.0 would be used instead.
Removing the explicitly set --self-contained false from the dotnet publish command seemed to do the trick for us. It defaults to the same, so why it makes a difference, I have no idea.
This was with SDK version 2.1.400.