While dotnet cli is not yet ready to work with Visual Studio and dnu/dnx gives me huge amount of extra unneeded libraries I want to do the following.
I want to launch ASP.NET Core 1 project either using command line or console app using traditional .csproj approach.
I created a ASP.NET 4 project, included all dependencies and was able to compile it.
1st Attempt.
At first I tried to compile it into console app and launch through standard entry point:
// Entry point for the application.
public static void Main(string[] args) {
WebApplication.Run<Startup>(args);
}
It says: "No service for type 'Microsoft.Extensions.PlatformAbstractions.IApplicationEnvironment' has been registered."
Which means that dnx.exe creates additional dependency injection rules probably through PlatformServices.Create.
Does somebody know how to do it properly?
2nd Attempt
I compiled it into dll and tried to launch it through dnx.exe which gave me the error "Error: Unable to load application or execute command 'Microsoft.AspNet.Hosting'. Available commands: web.".
Here's my project.json:
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"webroot": "wwwroot",
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://*:5004"
},
"frameworks": {
"dnx451": {}
},
"entryPoint": "ManagementConsoleWeb",
"loadable": false
}
So what's the proper way? Is is possible at all?
Here're some thoughts.
ASP.NET Core 1 requires DNX bootstrap to work. Yes, it works under .NET 4.5.2 but DNX is a must. So basically it's strange you can reference ASP.NET Core 1 libraries in .csproj net451.
DNX bootstrap libraries are not available under Nuget for net451 moniker. So you can't reference them from .csproj
That means you can't DEBUG ASP.NET Core 1 using traditional .csproj class library or executable approach. Of course you can always connect to a running app but that's not convenient.
So our team now is working with DNX bootstrap for NET CORE 1 but we deliver outputs from .csproj build until RC2 release.
ASP.NET Core 1.0 uses IHostingEnvironment hostingEnvironment instead of IApplicationEnvironment applicationEnvironment.
Go through the ASP.NET Core Migration document for full detail.
Related
I am developing a web application using Asp.NET Core 2.1 on Visual Studio 17.7, the problem is when I publish the web app as a Framework-Dependent and I try to run the app on production machine I get this error message:
Error:
An assembly specified in the application dependencies manifest (Example.deps.json) was not found:
package: 'Cronos', version: '0.6.3'
path: 'lib/netstandard1.0/Cronos.dll'
Cronos.dll is a dependency of Hangfire library which I am using in the web app, in the Example.deps.json file I found this:
"Cronos/0.6.3": {
"dependencies": {
"NETStandard.Library": "2.0.3"
},
"runtime": {
"lib/netstandard1.0/Cronos.dll": {
"assemblyVersion": "0.6.3.0",
"fileVersion": "0.6.3.0"
}
},
"compile": {
"lib/netstandard1.0/Cronos.dll": {}
}
},
The problem is that it's referencing the libraries in the runtime store, which will work on the developemnt machine but when I deploy to another machine the error happens.
I have tried the suggested solution in this article:
https://learn.microsoft.com/en-us/dotnet/core/deploying/runtime-store
By setting:-
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
and I have also tried solutions in this github issue with no success:
https://github.com/dotnet/coreclr/issues/13542
When deploying a .NET Core application, only use the publish output from the bin/Release/netcoreapp*/publish or …/netcoreapp*/{RID}/publish (when using -r RID option) or call dotnet publish with an -o ../target-dir option to specify a publish target location.
The build output (bin/Release/netcoreapp*) is meant for development purposes only since the runtimeconfig.dev.json file configures .NET Core to use packages directly from your NuGet package cache which avoids copying assets during the development builds.
I'm wonderinf if it possible to deploy my asp.net core application if I also use some library from .NET 4.5.2.
To describe my problem, in my app I use SyndicationFeed which comes from full .NET
and in my project.json in "framework" section I have:
"frameworks": {
"net452": {
"frameworkAssemblies": {
"System.ServiceModel": ""
},
"dependencies": {
}
},
"netcoreapp1.1": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.1.0"
}
},
"imports": [
"dotnet5.6",
"portable-net45+win8"
]
}
}
In the other sections I use ASP.CORE packages like:
"Microsoft.EntityFrameworkCore.Design": "1.1.0",
"Microsoft.EntityFrameworkCore.Tools": "1.1.0-preview4-final",
"Hangfire.AspNetCore": "1.6.8",
and more.
So the question is is it possible to deploy to the IIS. Should I deploy to server with run with ASP.CORE or full .NET.
In short: yes, it's possible. But full .NET Framework required (on server).
Long story:
Having two frameworks in projects.json effectively creates two different apps (one for net462, other for netcoreapp1.1) during compilation/publishing. This is two different applications, compiled for different frameworks from same source code.
To run first (for net462) you need machine with .NET Framework installed. For other (for netcoreapp) you need .NET Core installed. You can't "swap" (run net462-build app on .NET Core and vice versa).
But looking at your project.json I can't believe your app compiles successfully. You need System.ServiceModel for your app to work. But it's available only for net462. This means that during compilation first app (for net462) compiles successfully, while second (net netcoreapp) should fail (class not found, namespace not found, etc).
Run dotnet build or dotnet publish from command line in project/solution folder. See any errors?
So, you can't create/build/run under .NET Core while you need packages/classes not available for .NET Core.
Possible solutions:
Replace package for netcore-compatible (if any exist, I don't know), or re-build (port) existing to be compatible (as Joel says);
Completely remove this package (implement required code yourself);
Do not target netcoreapp1.1;
Add conditional compilation (#if) where you use this package, so you will use if only in net462-version of your app. Otherwise (#else) add NotImplementedException, null result or something other (it depends) - effectively you will have two different apps after compilation: full-functional for net462 and restricted-functional for netcoreapp.
I have an app on ASP.NET 5 (CoreCLR) and I try to publish it to the Microsoft Azure. I using free Web App (not VDS)
I am publishing app using Visual Studio 2015 Publish->Microsoft Azureand following this instructions.
But when I publish it and try to open, I see just non-stop loading of empty page. I enabling logging and view the log (stdout.log) from Azure and there was only:
'"dnx.exe"' is not recognized as an internal or external command,
operable program or batch file.
Also I tried to do Continiusly publishing with git. During push, It started restoring packages and failed with error no disk space available.
Is there any way to publish ASP.NET 5 app to the Azure Web App?
Short Answer
But when I publish it and try to open, I see just non-stop loading of empty page.
This happens when our app fails to publish the runtime (dnx.exe) with the application.
Discussion
There are several ways to publish ASP.NET Core rc1 apps to an Azure Web App. These include continuous deployment with Git and publishing with Visual Studio. Post your repository's contents for specific help.
The example is an ASP.NET Core rc1 app, deployed to an Azure Web App, via GitHub continuous deployment. These are the vital files.
app/
wwwroot/
web.config
project.json
startup.cs
.deployment <-- optional: if your app is not in the repo root
global.json <-- optional: if you need dnxcore50 support
app/wwwroot/web.config
Add the HttpPlatformHandler. Configure it to forward all requests to a DNX process. In other words, tell the Azure Web app to use DNX.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler"
path="*" verb="*"
modules="httpPlatformHandler"
resourceType="Unspecified"/>
</handlers>
<httpPlatform
processPath="%DNX_PATH%"
arguments="%DNX_ARGS%"
stdoutLogEnabled="false"
startupTimeLimit="3600"/>
</system.webServer>
</configuration>
app/project.json
Include a dependency on the Kestrel server. Set a web command that will startup Kestrel. Use dnx451 as the target framework. See below for the additional work to target dnxCore50.
{
"dependencies": {
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final"
},
"commands": {
"web": "Microsoft.AspNet.Server.Kestrel"
},
"frameworks": {
"dnx451": { }
}
}
app/Startup.cs
Include the Configure method. This one adds an extremely simple response handler.
using Microsoft.AspNet.Builder;
using Microsoft.AspNet.Http;
namespace WebNotWar
{
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(async (context) =>
{
await context.Response.WriteAsync(
"Hello from a minimal ASP.NET Core rc1 Web App.");
});
}
}
}
.deployment (optional)
If your app is not in the repositories root directory, tell the Azure Web App which directory contains the app.
[config]
project = app/
global.json (optional)
If you would like to target .NET Core, tell Azure that we want to target it. After adding this file, we can either replace (or complement) the dnx451 entry in our project.json with dnxCore50.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}
Firstly, yes, you can happily run ASP.Net 5 core apps on Azure, but there are some gotchas.
I don't know why it doesn't work when you publish from Visual Studio itself (so why is he posting an answer I hear you ask...), but here are some things to have a look at;
Try running in IIS locally (rather than kestrel) - just to see if there is a problem. For example, you need a Web.config with some settings or you need the app.UseIISPlatformHandler in startup.cs.
Have a look at your global.json file. It shouldn't matter when you publish from Visual Studio but it won't hurt to set this correctly. You can do something like this:
.
{
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "coreclr",
"architecture": "x64"
}
}
Regarding continous publishing - that is a known problem with free and shared sites and one that cost me a few hours. Basically, when you are deploying by this mechanism and you specify corecelr, the entire runtime is re-installed from Nuget and that takes up nearly 1GB (the allowance for free and shared sites). Add a few NPM packages and you are over the limit and, hey presto, you can't deploy. #shanselman discussed it recently on one of his podcasts. It's not actually the runtime binaries that take up all the space, but because we are in build mode, all the documentation XML files are installed as well, because Nuget doesn't know you are not in a development environment, and they are huge.
Right now, the simplest answer if you want to use continuous publishing on a free or shared site is to also include the full runtime in your project.json and set your global.json to use the full CLR instead of the coreclr. Just very frustrating.
I was having the same problem. This answer solved the issue.
When creating a new project with the asp.net core template the global.json file was part of my API project, but it was also referenced in the Solution Items folder. When published to an Azure API app, two global.json files were deployed:
In the /approot/global.json
In the /approot/src/MyAPI/global.json
I moved the global.json file out of the project folder to the solution root, and re-added a reference back into the Solution Items folder.
When deployed only the /approot/global.json file was then deployed, resolving the issue.
Today, I was following multiple tutorial to run a C# application on Linux but always got stuck at the command dnu restore which was returning me a not found error. Later on, I found out this page which seems to indicate that the new command is dotnet restore and when I tried it, it worked.
Are the dnu and dnx commands completely replaced?
Also, is there some documentation somewhere about the dotnet commands?
Is the dotnet command replacing dnu and dnx commands?
Yes. They are introducing new command line toolchain, ASP.NET 5 will transition to the new tools for RC2. This is already in progress. There will be a smooth transition from DNX to these new .NET Core components.
Are the dnu and dnx commands completely replaced?
No. You can use dnu and dnx, if you follow this instruction Installing .NET Core on Linux.
Is there some documentation somewhere about the dotnet commands?
CLI Repo / Intro to .NET Core CLI - v1.0.0
Here the basic things
1 dnu restore & dnx run works for version 1.0.0-rc1-update2 coreclr x64 (check using dnvm list) and project.json file needs minimum
"compilationOptions": {
"emitEntryPoint": true
},
"frameworks":{
"dnxcore50":{
"dependencies": {
"System.Console":"4.0.0-*"
}
}
}
2 dotnet restore & dotnet run works for version 1.0.0-rc2-23811 and project.json file needs minimum
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"NETStandard.Library": "1.0.0-rc2-23811"
},
"frameworks": {
"dnxcore50": { }
}
Along with this need NuGet.config file.
Now, based on How project.json file configured and dnvm active set, you need to use command.
I am trying to use Process.Start in an ASP.NET Beta8 project that I would like to be able to run on Linux using .Net core. Visual studio is giving me an error at compile time:
Error CS0103 The name 'Process' does not exist in the current context
Going back and hovering my mouse over Process.Start I can see a message that says "DNX core 5.0 not available". Is there a different way of invoking processes in asp.net 5? Or perhaps this isn't possible yet?
Here is exactly how I am using it:
var p = Process.Start("someprog", "someargs");
p.WaitForExit();
So it was me not really not knowing how the new project system works for .net. I needed to add a dependency to my project.json:
"frameworks": {
"dnx451": { },
"dnxcore50": {
"dependencies": {
"System.Diagnostics.Process": "4.1.0-beta-23409"
}
}
},
Adding this made it compile. Although I am not sure if that version number is correct.