I am developing a Web Application with ASPNET Core 2.0 on Visual Studio Code on Linux. But the host I'm trying to deploy the application is a Windows Server and the only target available option is .Net Framework 4.6.
So, when I try to run dotnet publish -o /folder -f net461 it shows me
this error.
Is it possible to develop an aspnet core application on linux and deploy it on windows using .Net Framework?
The following is the text of the error:
/usr/share/dotnet/sdk/2.0.0/Microsoft.Common.CurrentVersion.targets(1122,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.1" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/home/maransatto/Projects/FATEC/EraDoConhecimento/web/BDAg.csproj]
There are 2 scenarios: ASP.Net Core with .Net framework and ASP.Net Core with .Net Core. You can't develop asp.net core with .net framework on linux, so probably your application's target is "netcoreapp2.0" (suposed you downloaded the latest version). It's ok you deploy your app on windows server just using .net core runtime 2.0.
your command should be
dotnet publish -c Release -f netcoreapp2.0
You can deploy Framework-dependent or self-contained version. See (https://learn.microsoft.com/en-us/dotnet/core/deploying/index).
You also need Asp.Net Core Module on windows with IIS Integration.
https://learn.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x
When publishing self-contained you don't need .net core to be installed on the server.
Related
I've uploaded an asp.net core app with VS 2019 publish, and targeted the app netcoreapp2.2.
The app worked perfectly, but when checking some performance issue, I've noticed that in Azure portal-Configuration-General settings, the app stack settings was .NET (not .net core), and version is V4.7.
This raises 2 questions:
1. How is it even working...?
2. Why VS deployment process wasn't configured with the settings displayed in publish section?
VS publish settings:
Azure settings:
Thanks!
I fixed the issue by updating the following lines in .sln
from:
Visual Studio Version 16
VisualStudioVersion = 16.0.29613.14
To:
# Visual Studio Version 16
VisualStudioVersion = 16.0.30011.22
ASP.NET Core 2.x can target .NET Core or .NET Framework. ASP.NET Core apps targeting .NET Framework aren't cross-platform—they run on Windows only. Generally, ASP.NET Core 2.x is made up of .NET Standard libraries. Libraries written with .NET Standard 2.0 run on any .NET platform that implements .NET Standard 2.0.
When you published to the .NET Core 2.2 runtime app you would always get the following warning message:
"There was a problem starting MyProjectName on MyWebAppServiceName. Your application requires the .NET Core 2.2.0 runtime, but Microsoft Azure App Service only support the following versions:.
One way to fix this problem is by changing the deployment mode to self-contained in the publish settings, which will allow the application to carry its own runtime."
Refer to this similar case.
Edit:
When you create webapp on portal, you could go to arm template to get the stack setting which is set as CurrentStack: dotnetCore. But when you publish project on VS, it could net set the runtime.
So, it may a VS issue that you could give feedback or you could create webapp on Azure first which set runtime as .Net Core and publish project to it using VS.
I am planning to buy a Linux server. I have some APIs written in .NET Core (C#) and so I will be installing only .NET Core on my sever.
When I deploy my APIs, will they work with only .NET Core or will there be some dependencies on .NET Framework, too?
If you will be running the .Net core via kestrel server, you won't be having any dependency on .Net framework for execution.
More details on https://stackify.com/what-is-kestrel-web-server/
Net Core is “bundled” so it runs isolated anyway.. Go with the new Net Core and you’ll be fine. It has no dependencies in Net Framework
I have this issue in which I'm currently targeting .NET Framework 4.7.2 in my solution but the Azure Web App Service only supports up to .NET Framework 4.7.1. So, my question is this: As long as I only use 4.7.1 features, should it work without issue on the Azure Web App Service (which only supports up to 4.7.1) even though I'm targeting 4.7.2? Are the .NET Frameworks backwards compatible? So far, I haven't seen any issues. I just want to make sure there will be no future complications. Ideally, I would like to keep targeting 4.7.2 so that I can start using the 4.7.2 features once it becomes available on Azure Web App Service.
The .NET Framework 4.7.2 builds on previous versions of the .NET Framework 4.x by adding many new fixes and several new features while remaining a very stable product.
The .NET Framework 4.7.2 is included with the Windows 10 April 2018 Update
The .NET Framework 4.7.2 can be used to run applications built for the .NET Framework 4.0 through 4.7.1.
Azure App Service now supports 4.7.2
I think that you did a good thing in upgrading and targeting .NET Framework 4.7.2 ; I also have an Azure App Service and upgraded it to 4.7.2 and it is running very well. As said before, it brings updates and fixes, and it is backward compatible on almost all cases.
Note that the recommended is that the target machine have a .Net version Equal or Greater of the of the .NET Framework 4.x than your compiled version.
See:
https://learn.microsoft.com/en-us/dotnet/framework/whats-new/index#v472
https://learn.microsoft.com/en-us/dotnet/framework/install/on-windows-10
#TheDude, you cannot build an app on 4.7.2 and hope to run it on lower version like 4.7.1. At runtime the target framework version check will fail as it will find the Framework version (4.7.2) as missing.
The other way round (i.e. target 4.7.1 and run on 4.7.2) is fine as the higher versions are backwards compatible.
I have a test project int Core 2 console (Core2ConsoleTest).
It make a reference to .NET Framework 4.6.1 Project (NetFrameworkTest).
NetFrameworkTest project references the standard System.Printer.dll.
Download Core2ConsoleTest project here
When I call to any System.Printer function I have the error: Could not load file or assembly 'System.Printing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. El sistema no puede encontrar el archivo especificado.
I tested with other standard libraries like System.Windows.Forms.dll and the same error if the Core project references a Nuget Package that uses standard libraries.
Note: The same error with ASP.Net Core 2
Thanks for your help!
This is not going to work on .NET Core.
.NET Core 2.0 has a compatibility layer that allows loading and using .NET Framework libraries but this only works as long as this library only uses types and methods that are also available on .NET Core.
Since System.Printing is not part of .NET Core, this library will fail to access it with the exception you posted.
Only .NET Framework applications can use this API (e.g. an ASP.NET Core on .NET Framework application).
I really have the problem with ASP.Net Core Framework Project. I'm unable to create a new Project with Core 2.0 and reference a Framework library that references System.Printing.dll or other libraries.
But #mairaw gave me another way: On a project that works in Core 1.1, updating the libraries Nuget to 2.0, works correctly.
So it looks like a Visual Studio 2017 problem or Core templates.
My concern is to remove this functionality, because it allows to adopt the Core technology in a staggered way with a high code reuse.
Edit: Added sample projects
CoreTest.zip -> A ASP.Net Core Framework Project created referencing Core 1.1 and .NET Framework 4.6.1 in the past, then upgraded to Core 2.0 using Nuget: WORKS!
Core2Framework.zip -> A similar project (ASP.Net Core Framework Project created referencing Core 2.0) created with Visual Studio 2017 15.3.4: ERROR when calling System.Prinig.dll from the .NET Framework 4.6.1 Project.
I installed VS 2017 along with .NET Core SDK on Windows 10. But it did not install ASPNETCoreModule as shown in figure 2 below. I thought .NET Core SDK should have installed it implicitly - and one does not have to install it separately. NOTE: I'm trying to publish my asp.net core app to IIS and the publish process requires ASPNETCoreModule as explained in the above link and also in this official MSDN article.
ASPNETCoreModule is missing:
ASP.NET Core Module is installed separately from the SDK. You can download the current version 2.0.0 here. https://github.com/dotnet/core/blob/master/release-notes/download-archives/2.0.0-download.md#windows-server-hosting
See https://github.com/dotnet/core/blob/master/release-notes/download-archive.md for a list of other releases.
ASP.NET Core Module is installed separately from the SDK
It's not true since the release of 2.1. I'm experiencing the same issue on Windows Server 2016. The module was installed on developer PC after uninstalling old versions / installing 2.1 a few times, but still struggling with the same issue in 2016. %SystemRoot%\system32\inetsrv\aspnetcore.dll is still missing.
In order to run .net core apps on IIS you need to have installed the ASP.NET Core Module ( the way it works is explained here ) that comes:
1 - with the SDK 2.1,
2 - With the Hosting Bundle Installer that bundles the .Net Core and the ASP.NET Core Runtime into a single bundler.
you can have both from the download page
If you are a developer computer you already have the Module with the SDK, I think is better to have on Sever computer only the hosting bundle
First, you need to check your IIS configurations, in case Shared configuration is configured in your IIS then normal installation of dotnet hosting bundle package wont work,
to make it work you need to install bundle package by command line with the argument as below:
dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1
you can refer ASP.NET Core Module with an IIS Shared Configuration
This solution work for me because we are using the shared configuration in IIS