Since Visual Studio 2017 is released and we can use the new C# 7 features I expected this will work when deploying on Azure Web apps.
Unfortunately we're seeing compile errors when using continuous deployment (kudu git deploy) so it seems Azure doesn't support the new toolchain yet.
Is there anything we can do to get this to work now (besides publishing the assemblies directly)?
since we don't yet have msbuild15 in Azure.
if you want to use c#7 features with continuous integration, you may need some workaround
for dotnet core web solution, you can build it in Azure out of the box. (it uses its own dotnet msbuild.dll) [repository sample]
for asp.net web solution, you need to add Microsoft.Net.Compilers 2.0+ nuget package to the project where the new language feature is applied. For example, if a class library in the solution is using the new syntax, you need to add nuget package to that lib project. (the new c# compiler is thus imported if you refer this nuget package) [repository sample]
finally for mixed solution (dotnet core web app + .NET framework class lib), you need to run nuget restore for the .NET framework lib project independently since dotnet restore is not backwards compatible, it cannot retore project from the old build system. I did this by hacking my deploy.cmd [repository sample]
these workarounds either try to
imitate msbuild15 (case1: dotnet msbuild.dll, case2: compiler as a nuget package)
or imitate nuget4.0 (case 3: run both dotnet restore and nuget3.5 restore)
we are in the process of building these tools for Azure, they should be out soon. you can stay updated on github
Adding the Microsoft.Net.Compilers NuGet package fixes the issue.
As pointed out by #joshuanapoli in a comment to the accepted answer Scenario #2 works only with Microsoft.Net.Compilers v2.4.0 and below.
Took me a couple of hours to notice and figure it out.
Related
I have an ASP.Net Core 2.2 application.
MyApp.Sln
MyApp.API (ASP.Net Core 2.2 API Based project)
MyApp.Services (CL-Class Library)
MyApp.Contracts - (CL-Class Library)
My.Services.Tests - (CL-Class Library)
The above projects have different libraries(NuGet packages) installed
In .Net framework we used to have packages.config thats lists the nuget packages with the version details.
Where I can find the same details in .Net Core 2.2 ?
Because different project in one sln should not have different version of NuGet.
Thanks!
You can right Click in Your project in Solution explorer and Edit(For example MyApp.Services.csproj) in this file you will See Packages
You can follow this link to see options
Default command
Running in the project folder - Shows all packages, by default
dotnet list package <optional project path or solution path>
I don't believe there is anything equal to packages.config in .Net Core (possible reason - it aims to be more modular). You will have to make a little bit of work to solve your issue.
The quickest way to get dependecy graph is to run
dotnet msbuild YourProject.sln /t:GenerateRestoreGraphFile /p:RestoreGraphOutputPath=graph.dg
from terminal. Then you can open it with any editor and view all your dependencies in one file.
If this file isn't enough for you, you will (unfortunately) have to do a little bit of dirty work. See this answer View nuget package dependency hierarchy for some really good solutions, like how to write your own application to print dependencies, or how to use NPM.
I got the below error while building the Enterprise Bot Template Project in VS2017. Not sure what i 'm doing wrong here.
Severity Code Description Project File Line Suppression State
Error CS1703 Multiple assemblies with equivalent identity have been imported: 'C:\Users\XXX.nuget\packages\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Runtime.Serialization.Json.dll' and 'C:\Users\XXX.nuget\packages\system.runtime.serialization.json\4.3.0\ref\netstandard1.0\System.Runtime.Serialization.Json.dll'. Remove one of the duplicate references. SovereignBot C:\Users\XXX\Documents\Visual Studio 2017\Projects\SovereignBot\SovereignBot\CSC 1 Active
Any ideas how to fix?
I'm not able to replicate this issue with a fresh install of the Enterprise VSIX template. This leads me to believe the issue is either in your code or on your machine.
After researching, it appears there could be a couple of problems and solutions:
Your Local/Development and Build servers use different versions of Visual Studio
Update Visual Studio for both environments
If you're still experiencing issues, try installing the Microsoft.CodeDom.Providers.DotNetcompilerPlatform NuGet package.
NuGet or .NET Core is out of date
Update NuGet
Update the appropriate .NET Core SDK. Currently, Bot Framework is supported well on .NET Core 2.2. Keep in mind that if you have 2.2 installed, you may need to update to the latest sub-version (v2.2.104, as of now). Keep in mind you may also need to upgrade your NuGet packages within the project in order to be compatible to the .NET Core SDK.
Ensure your bot is using the correct .NET Core Target Framework by right-clicking the Project > Properties > Application:
Your Visual Studio version doesn't handle dependency version collisions on its own
Update your Visual Studio
You have a duplicate reference to the same package (but possibly different versions) in your .csproj file
This is more likely if you're using code brought in from another project.
Delete or comment out the duplicate by right-clicking on your Project in Visual Studio, and clicking Edit .csproj:
You have a package installed via both NuGet and locally
(I don't believe this is the issue for you, since both of your packages appear to be in the NuGet directory)
Go to the file path of one of the dependencies and delete it.
I'm trying to use a Windows Service to host a simple ASP.Net Core web app targeting .Net core 2.x, as detailed here by Microsoft.
This should be simple with the docs, but I'm getting nowhere because the Microsoft.AspNetCore.Hosting.WindowsServices package doesn't seem to work with any version of .Net Core (the NuGet page says it depends on .Net Standard). Simply opening a project will cause Visual Studio to get stuck at NuGet restore, without any error message whatsoever (I have to kill the VS process manually, as closing VS would cause it to stop responding). Running dotnet restore from command will cause cmd gets stuck at "Restoring packages for XXX".
The same thing happens with the sample code in ASP.Net official docs. I guess this must mean a machine- or platform-specific issue to me but I have tried with various (fresh) VMs and am out of ideas. The only thing that works so far is this answer here, i.e targeting .Net Framework and explicitly list all the package references rather than using Microsoft.AspNetCore.All.
I'm using VS2017 15.7.6. Any help on this issue would be greatly appreciated!
Update
The problem magically disappeared after I installed the Azure development workload in VS2017. I already had ASP.Net and .Net Core workloads before, so I really can't figure out which individual component did the trick, but it did solve the problem.
Yes, this answer is correct. The windows-service package only runs on windows. You have to directly target each package you need, because the Microsoft.AspNetCore.App (.NET-Core >= 2.1) and Microsoft.AspNetCore.All (.NET-Core >= 1.1 <= 2.0) packages, contain package(s) that target .NET-Core instead of .NET-Standard.
You could target both frame-works using
<TargetFrameworks>net471;netcoreapp2.1</TargetFrameworks>
and have conditional includes in your project file + compiler directives in your c# code.
<!-- CSPROJ CONDITIONAL REFERENCE -->
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" Condition="'$(TargetFramework)' == 'net471'" />
// c#-code compiler directive
#if net471
using Microsoft.AspNetCore.Hosting.WindowsServices;
#endif
Keep in mind that using the full .NET-Framework will make you lose the performance improvements introduced with .NET-Core.
I am sure you could also have a batch script / windows task that starts your .NET-Core service each time your windows machine restarts.
I just had a similar problem. We have multiple Nuget package stores, and one of them was experiencing certificate issues.
I fixed it by doing the following:
Right-click on project Dependencies in Solution Explorer, and click Manage Nuget packages.
In the Package Manager, in the Installed tab, you should see the package, select the Microsoft.AspNetCore.Hosting.WindowsServices package. It will be showing a version 0 and some indication that it is failing to download.
You may also see the Package source in the top-right pointing to one of the custom Nuget stores. Change the Package Source to ALL. That will cause the window to refresh, and then you may see the correct version and an Update button.
Now click the Update button to update. My version is now 2.1.1.
Looking at the project file now, it changed the package reference to:
<PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.1.1" />
I'm not even sure if what I'm trying to do is possible...
Sample code: here
Basically, I've built a netstandard20 class library which according to the .NET implementation support list should be compatible with a framework461 project (providing you have the .NET Core 2.0 SDK).
I can build the netstandard20 class library no worries and get the DLL back (it's included in the sample code).
This is where the problem starts, when attempting to run msbuild .\netstandard_test.sln to build the framework461 project I get a whole bunch of (what I believe to be misleading) errors about 'netstandard' not being referenced (which it is).
However, if I run dotnet build (or build from VS2017) everything works as expected.
I've tried importing various versions of NetStandard, NetStandard.Library and NetStandard.Library.Framework, as well as referencing Microsoft.DotNet.BuildTools but that didn't appear to help.
Is there any way to build this using msbuild? We have a monolithic build and deployment process and I'd rather not have to change it if it can be avoided. Who knows what else would go wrong!
To build with .NET Core or .NET Standard you need to use the dotnet msbuild command from the .NET Core SDK rather than just plain msbuild.
dotnet msbuild .\netstandard_test.sln /p:Configuration=Release
This will also work with .NET Framework 4.6.1 (and older versions).
Do note that Microsoft has provided install scripts to make installing the .NET Core SDK painless on continuous integration servers.
You need to use a recent 15.* version (currently 15.5.*) of MSBuild and make sure that the "Cross platform development" workload is installed in visual studio. This adds the required components to locate the .NET Core SDK, which contains MSBuild SDKs like Microsoft.NET.Sdk or Microsoft.NET.Sdk.Web used by .NET Standard and .NET Core projects.
You can then use msbuild from the developer command prompt to build these projects. I suggest adding /restore (msbuild >= 15.5.*) to make sure that a NuGet restore happened for sdk-based projects.
Since VS 2017 does not install a "global" version of MSBuild, be sure to use the version of MSBuild installed in the VS 2017 folders (check with msbuild /version or where msbuild).
dotnet msbuild has limitations when you use .resx files containing file references or non-string properties. Also, it does not support COM references or building strong named assemblies. If you need any of these features, use msbuild (VS 2017) over dotnet msbuild (.NET Core CLI)
I was testing the Asp.NET Core authentication features. The project.json is copied from the GitHub exmaple. here
NU1001 The dependency Microsoft.AspNetCore.Server.Kestrel >= 1.0.0-* could not be resolved.
Other dependencies can be successfully resolved. And I also double checked my dnvm version.
The IntelliSense in Visual Studio also shows there is no Microsoft.AspNetCore... package in dependencies.
So if I want to add
app.UseOAuthAuthentication("Google-AccessToken", options =>...);
in Startup.cs, what is the correct dependency to use?
If you want to use the nightly builds, you need to add the nightly package repositories to do so.
First you will need to use the latest rc2 nightly runtime dnvm upgrade -u latest. Beware, it will fail to restore packages really often!!
You need to add the proper nuget feeds. The official nuget feed (https://www.nuget.org/api/v2) do not contain this packages, as they are nightly builds and pretty unstable. Official nuget feed only has rc1-final packages
From my experience these feeds worked well for rc2 for me
Old (now deprecated) DNX runtime: https://www.myget.org/F/aspnetvnext/api/v3/index.json
New dotnet-cli tooling: https://dotnet.myget.org/F/cli-deps/api/v3/index.json
If you want to try out dotnet-cli you need to install it and follow the instructions in my previous answer on how to run ASP.NET MVC on dotnet-cli found here.
That being said, Microsoft.AspNetCore.Server.Kestrel uses the new naming scheme, which means it's RC2 since Microsoft.AspNet.* packages where renamed to Microsoft.AspNetCore.* some time during RC2 cycle.
If you need a stable base to play around, use rc1-final and it's versions, as they won't be updates at any time and your package restore won't fail multiple times a week due to upgrade to the runtime or packages.
The samples in the dev branch always target the nightly builds, that's some RC2 nightly build at the time of the writing. You either have use the sample in rc1-final branch or switch to rc2 nightly (runtime and packages) and wait for rc2 to be released (hopefully soon).
You can find the rc1-final version of project.json in the rc1-final tag or directly here.