I am trying to publish a Netcore 2.0 application with MSBUILD.
The published output is missing all the SDK dlls such as Microsoft.AspNetCore.Hosting.dll (there are a lot) so when I try to run the application from command line with dotnet appname.dll I get the error saying that it can't find the referenced dll...
I have published other applications before (not created by me) and the publish copies the dlls and also has a "refs" folder which mine does not have.
So I am pretty sure it's a project configuration issue but I have been searching for hours and there is no information on what I should change.
Turns out there was a nuget reference on my project called Microsoft.AspNetCore.All...
For some reason uninstalling this reference solved the issue and now the publish output contains all the SDK dlls
The ASP.NET Core dlls are part of the runtime store that is included in the runtime & hosting bundle installations so they don't need to be included in the publish output. (note that this is going to change in the 2.1 timeframe)
To disable the use of the ASP.NET Core runtime package store, you can set this in your project file:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Related
I have a .NET Core Web Application. I'm using the publish command to create a self contained deployment.
It creates the files and appears to create .net core dlls, but when runnning in IIS on Windows 10, I still need to install the .NET Core Runtime to get it to work. After installing .NET Core Hosting bundle it works fine.
I have reviewed a lot of other posts before asking, but can't find the answer.
By default IIS gives the following error:
HTTP ERROR 500.19 – Internal Server Error
My Publish command:
dotnet publish "mydirectory\mywebsite.csproj" --self-contained --framework netcoreapp2.1 -r win10-x64 -c Release
The csproj looks like this:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<UserSecretsId>aspnet-mywebsite-656GASF8-B9H4-5963-1038-5D735B609E15</UserSecretsId>
<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>
</PropertyGroup>
Here are the published files.
I thought maybe the 'l1-1-0' part might be the wrong framework version, but my dotnet version is 2.1.500.
What do I need to do to get it to work please?
Lex Li's comment/ blog post contains the answer. I'm detailing it here to try to save someone else losing days to this simple misunderstanding.
A self contained deployment does indeed include the runtime, but
it doesn't include the ASP.NET Core module for IIS which you get
when you download the Runtime & Hosting Bundle from the .net downloads
page.
So if you are deploying to IIS, you will need to run the Runtime & Hosting Bundle installer even for a self contained deployment.
A self contained deployment just means the application will use the .NET Core Runtime packaged with the application rather than whatever is installed on the machine.
I have a DotNetCore 2.1 Web App (just created it today from the VS 2017 scaffold). This solution also includes a DotNet Core 2.1 Library DLL project. The solution builds ok.
I have another (brand new) DotNetCore 2.1 Web App that wants to use the Library DLL. But when I try to add a new reference (on the Browse tab), it complains:
One or more errors occurred.
The reference is invalid or unsupported.
Any suggestions?
(Curiously, the DLL doesn't show up directly under the Bin\Debug folder like it does in classic .Net; It's under Bin\Debug\netcoreapp2.1)
I got this error after I moved some of my code repos around and suddenly my .NET Core 2.1 console app wouldn't recognize a .NET 4.5 DLL anymore when I added it.
Turned out that although the broken reference did not show in the solution explorer, the project file still contained it, along with the now broken HintPath to the DLL's old location. Manually removing this reference from the project file solved it.
Go into your .csproj and make sure the <Reference Include=... is pointing to the correct directory.
For example, my references were pointing to the bin\Debug path of another project when the only build that was actually there was the bin\Release
When you create a new project from the Visual Studio 2017 Class Library (.NET Core) template, the csproj file contains:
<TargetFramework>netcoreapp2.1</TargetFramework>
Since this is a library, it (apparently) needs to target netstandard2.0. (BTW, creating a library project from the dotnet command line command correctly targets netstandard2.0. Go figure.)
So changing the line in the library's csproj file to
<TargetFramework>netstandard2.0</TargetFramework>
and rebuilding the library now allows me to reference the library from the DotNet Core 2.1 (netcoreapp2.1) application.
I am converting lots of projects to .net6, and one of the projects suddenly refused to let me add .dll files. The solution was to remove the old references first, then add the new references. (The project had references to old .dll files with the same name as the new converted ones.)
Normally Visual Studio lets me add two dlls with the same name but different path, so I later can erase the old one, but in this particular case this did not work. A screenshot and Paint to the rescue for my memory!
In my case, I had a reference to duplicated .dll files. After removing duplication and changing references to different folders got the error above. Cleaning obj, bin and removing the .vs folder from the root directory helped
For me I had to add a nuget package instead of manually adding a reference. I was using .net 6 and needed System.Drawing so I added the System.Drawing.Common package.
https://www.nuget.org/packages/System.Drawing.Common/
In .net core 2.0 I add some nuget package.Project work in local but does not work in server-production.I click solution and click publih to folder and move that folder to server.But in published folder there is no this nuget dll
how can I publish that nuget dll?In that folder I didnt find that dll
C:\Users\HC.nuget\packages
I think the problem is all of those packages are included in the ASP.NET Core Implicit Store. These are only present however, if the SDK is present on the target machine. If this is the case you have 3 options.
Install the .NET Core SDK (not just the runtime) on the target machine. In this case the implicit store will be present.
Set the following property to false:
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
This will cause the build to include dependencies that are in the implicit store so that the final published product only relies on the .NET Core Runtime and not the API.
Build a self-contained deployment
This will bundle everything (runtime and implicit dependencies) into your application.
I am working with .Net Core 1.0 (running under the .Net Framework 4.6.1, non-portable).
I need to include some DLLs that are from a locally-built GitHub project. When I build those projects, and then attempt to "Add Reference" to the resulting DLLs, I get a message saying I can't add them to a Core project directly.
After more research, I found a lot of information regarding "private" NuGet packages. However, those seem overly complex / overly engineered.
Is there any way I can do the following:
Without having to go through the headache of creating a private NuGet repository, can I just "add reference" to the built assemblies that are sitting in the bin folder of the NuGet projects I pulled?
I really don't want to have to build a local-only NuGet package. Mostly because I've already wasted too much time on this issue, and because I read this entire concept is about to be scrapped and turned into something else (sounds familiar by now)... such as the Roslyn-based build system on GitHub.
My current state:
Visual Studio Professional 2015
.Net Core 1.0.1
.Net Core 1.0.1 Tooling Preview 2
No, as for now you have to create a nuget package before and restore it via Nuget. You can use a simple folder as NuGet source, so if you put your compiled NuGet package in C:\packages, you can add this as a source to NuGet (while in the NuGet UI, click the settings Icon and add the folder as new source).
This may change with the next release of ASP.NET Core (1.1), as the .NET/ASP.NET Core team is working to move from *.xproj to *.csproj files.
One of the reasons why you need to use nuget is because it can contain multiple targets and project.json allows you to target multiple platforms (i.e. net452 and netcoreapp1.0).
I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.
The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish
After turning up log verbosity and reading through the relevant msbuild files I have learned the following:
The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.
However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.
If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.
My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?
EDIT:
For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild.
This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.
To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.
msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App.
[deep breath]
On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)
Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3
Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>
I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:
/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true
This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.
I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:
<GetRuntimeVersion
Condition="'$(IgnoreDNXRuntime)' != 'true'"
RuntimeVersionOverride="$(PublishDNXVersion)"
TargetDNXVersion="$(_DefaultDNXVersion)"
RuntimeToolingVersion="$(RuntimeToolingVersion)"
Want64Bit="$(Bundle64BitRuntime)"
WantCoreClr="$(BundleCoreClrRuntime)">
<Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>
There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)
Good luck!