In a continuous deployment scenario I'm trying to deploy a .Net core web application on IIS starting from a clean machine. During the automated tasks I download and execute the dotnet-install.ps1 script that is responsible of installing the .Net runtime in the user's %LocalAppData%\Microsoft\dotnet folder.
Now I need to provide IIS with the AspNet Core Module that allows it to run .Net core applications, but I found that the only way to install it is to download the .Net core runtime from the official web site and install it.
Instead, what I would like to do is to preserve the way I install the .Net core runtime via the dotnet-install.ps1 script (which automatically checks for upgrades and handles all the installation) while being able to install only the IIS AspNet Core Module.
Is there any installation method to support me installing only the IIS AspNet core module?
Thanks
Related
I'm getting more and more confused with .NET Core's SDK and runtime versioning, and I doubt I'm the only one. I want to get a few things straight.
I've created an ASP.NET Core application targeting .NET 4.6.1 - it hits 4.6.1 libraries and Net Standard libraries. Recently I made the switch from project.json to csproj as part of the VS2017 rollout. The 1.1.1 runtime came out with SDK 1.0.1 a few weeks ago, which I downloaded (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
dotnet --version gives me the correct SDK (1.0.1)
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime is installed.
Fast forward to hosting my app: I install the latest windows server hosting package to host on IIS according to https://learn.microsoft.com/en-us/aspnet/core/publishing/iis, that is 1.0.4&1.1.1. Installing this on my server installs "Microsoft .NET Core 1.0.4 & 1.1.1 - Windows Server Hosting" and "Microsoft .NET Core 1.0.4 - Runtime". Shouldn't it have also installed the 1.1.1 runtime? It works, so maybe it's not necessary.
Ultimately, my questions are the following:
Does the runtime version matter when targeting .NET 4.6.1 at all?
Is runtime just used to run the AspNetCoreModule for the IIS to kestrel reverse proxy?
Will installing new Windows Hosting packages break existing projects already running on the servers?
Does .Net's netstandard packages (such as MVC) versioning correspond in any way to the runtime version, or is it just regular semantic versioning? The newest versions of most "Microsoft.AspNetCore.X" packages are 1.1.1.
I'm in the same situation, compiling my ASP.NET Core app against the full .NET Framework (4.5.2 in my case) and deploying it on IIS. Hopefully I can help.
When using the full .NET framework, you need to install the SDK on your developper machine to compile, but to deploy it on an IIS server you don't need any .NET Core runtime installed at all. On my IIS server, I just need .NET Framework installed and then I'm installing the "Windows Server Hosting" as suggested here: https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.0.4-download.md with a command line that won't even install any .NET Core on my server:
DotNetCore.1.0.4_1.1.1-WindowsHosting.exe OPT_INSTALL_LTS_REDIST=0 OPT_INSTALL_FTS_REDIST=0
This installation is super quick and is just deploying the minimum amount of files IIS needs to run your .NET Core app, which is mainly the aspnetcore.dll. I don't even have a directory "C:\Program Files\dotnet" (so no runtime or sdk) on my server and my app is working fine.
So, I would say:
no, it doesn't matter, it won't run against any .NET Core runtime
no, AspNetCore.dll is a C++ module (https://github.com/aspnet/AspNetCoreModule)
I don't see how it could break anything
at the moment, when you add a Nuget package in your ASP.NET Core app, its versionning seems quite independant to me, that's why Microsoft is now providing metapackage to help people using the proper set of Nuget package (https://andrewlock.net/what-is-the-microsoft-aspnetcore-metapackage/)
Regarding:
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't
this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime
is installed.
I'm wondering the same thing and can't figure out where this is coming from, maybe it's just the version of the "dotnet" command line tool that is package with the SDK 1.0.1, but I can't prove it.
I have an ASP.NET Web application that was successfully running on Linux with the help of dnx-mono NuGet package. I used to publish it by using dnx publish tool and run it with the command:
/opt/dnx-mono.1.0.0-rc1-update1/bin/dnx --appbase /path/to/json Microsoft.Dnx.ApplicationHost kestrel
Since dnx is obsolete, I want to get rid of it and migrate to .NET Core, but it does not work anymore on Linux.
Important: I cannot make my application .NET Core app because it uses some libraries (like MySQL.Data) that are still not available for .NET Core. Therefore, I create ASP.NET Core Web Application (notice .NET Framework):
I migrated the whole application and run it successfully on Windows, but my target is Linux. No more dnx publish, no problem - there is dotnet publish which works well and produces binaries. What now? Dnx-mono package does not have a "dotnet-something" successor, and using dotnet command with published binaries produced errors that I was not able to resolve (The library 'libhostpolicy.so' required to execute the application was not found), but I don't think that I should even use dotnet command with standalone binaries. Googling didn't help as most tutorials are focused around ASP.NET Web applications for .NET Core, not for .NET Framework. Version of Linux is Debian 8, dotnet command was obtained by following this guide. Any clue?
You cannot run an application on Linux that targets the full .Net Framework, it has to be Core only.
I am trying to deploy an asp.net web app from BitBucket to an Azure web app and getting the below error:
Command: "D:\home\site\deployments\tools\deploy.cmd"
Handling ASP.NET Core Web Application deployment with MSBuild.
MSBuild auto-detection: using msbuild version '14.0' from 'D:\Program Files (x86)\MSBuild\14.0\bin'.
Restoring packages for D:\home\site\repository\src\Sertech\project.json...
Committing restore...
Lock file has not changed. Skipping lock file write. Path: D:\home\site\repository\src\Sertech\project.lock.json
D:\home\site\repository\src\Sertech\Sertech.xproj
Restore completed in 1753ms.
NuGet Config files used:
C:\DWASFiles\Sites\#1SertechWebApp\AppData\NuGet\NuGet.Config
Feeds used:
https://api.nuget.org/v3/index.json
Cannot find DNX runtime dnx-clr-win-x86.1.0.0-rc1-update1 in the folder: .dnx\runtimes
D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(248,5): error MSB4044: The "GetBuildOptions" task was not given a value for the required parameter "RuntimeToolingDirectory". [D:\home\site\repository\src\Sertech\Sertech.xproj]
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "D:\home\site\repository\Sertech.sln" /nologo /verbosity:m /p:deployOnBuild=True;AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false;publishUrl="D:\local\Temp\8d3d203fca67f23"
An error has occurred during web site deployment.
\r\nD:\Program Files (x86)\SiteExtensions\Kudu\57.50831.2397\bin\Scripts\starter.cmd "D:\home\site\deployments\tools\deploy.cmd"
The Publish Web option in Visual Studio works just fine, the issue only happens from a BitBucket deployment.
What I've tried so far in no particular order:
Use custom deployment script I found while searching the issue.
Use custom deployment script downloaded from the Kudu page of my
Azure web app.
Change the SDK version in VS.
Install the dnx-clr-win-x86 nuget package locally.
Install the dnx-clr-win-x86 nuget package on the web app resource
using the Azure console (this failed to find a package).
If anybody can point me in the right direction for troubleshooting further or has a solution I would be very thankful.
DNX? RC1? A release candidate isn't quite RELEASED software. Just as The Donald isn't the president just because he's a candidate (well at least not as of this writing).
ASP.NET 5.0 betas, Core 1.0 RC1 and Core 1.0 RC2 are no longer supported in Azure App Service.
Admittedly this was announced in a blog post so visibility may suffer - https://blogs.msdn.microsoft.com/waws/2016/06/14/supporting-asp-net-5-core-rc1-on-azure-app-service/
Is ASP.NET 5, Core RC1, RC2 supported on Azure App Service?
No, ASP.NET 5, Core RC1 or RC2 is no longer supported on Azure App Service. The only supported ASP.NET Core stack is RTM on Azure App Service. Check the newly announced RTM version at https://blogs.msdn.microsoft.com/appserviceteam/2016/06/27/azure-app-service-and-asp-net-core/
No wonder you see things breaking. Upgrade your project to ASP.NET Core 1.0 RTM and redeploy.
Official migration guide here:
https://docs.asp.net/en/latest/migration/rc1-to-rtm.html
In this video, Scott Hanselman interviews a guy from the ASP.NET team. He says that one of the goals of ASP.NET 5, on top of .NET Core, is that the apps won't depend on the .NET Framework and GAC assemblies on the hosting server. Instead, .NET Core libraries will be released via NuGet packages and apps will be deployed with their dependencies.
One of the reasons for this is so Microsoft can quickly release a bug fix or new feature, and we don't have to wait until the new version (of the full framework) is installed on our hosting environment.
My question is:
Are the apps built on .NET Core really independent of the version of .NET installed on the target machine, and can they run even without the .NET Framework installed?
Yes, the framework you use in your application is completely independent of the .NET Framework installed on the target server, because the Core .NET Framework is referenced via NuGet packages and can be bundled up for deployment via the DNX Utility, specifically of interest to you will be the dnu publish command.
Here is an excerpt, describing what dnu publish does:
Publish (dnu publish)
The publish command will package your application into a self-contained directory that can be launched. It will create the following directory structure:
output/
output/packages
output/appName
output/commandName.cmd
The packages directory contains all the packages your application needs to run.
The appName directory will contain all of your applications code, if you have project references they will appear as their own directory with code at this level as well.
So the .NET Core will exist in the output/packages directory and will not need to be installed on the target server.
A normal .net core app requires that you install .net core on the machine you wish to run the application on. There is a way to avoid this however, by publishing a self contained app. You can publish your app with the requisite version of .net core included. This will make your app larger, but if you only need one application on a machine to run .net, you need a specific version of .net, or you want to make a portable application, this is a good choice.
I wrote an ASP.NET web application with an installer. For the installer, I'm using the Web Setup Project under the Setup and Deployment project types in Visual Studio 2008.
How do I set the IIS File Security to Integrated Windows Authentication on only one .aspx page or directory during the installation process using a Web Setup Project? If it is not possible with the Web Setup Project how would I automate that task?
Currently I'm installing the application with the installer and manually setting the security permissions.
Look at the CustomAction Class for the Install Method.
Here's a sample:
http://www.codeproject.com/KB/install/SetIISettings.aspx