I wrote a tool at work in .NET 5.0 that I now have to give to a non-developer to use. Unfortunately, no matter how I publish it I can't get it to run on her computer. Currently I have it set at:
Configuration: Release | Any CPU
Target framework: net5.0
Deployment mode: Self-contained
Target runtime: win-x64 (checked that, she definitely has Windows 10 64-bit)
But when she runs it on her PC she gets:
Failed to load the dll from [C:\Users\username\Desktop\Release Builder\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Users\username\Desktop\Release Builder\hostfxr.dll failed
- Installing .NET prerequisites might help resolve this problem.
https://go.microsoft.com/fwlink/?linkid=798306
I, of course, checked the link and she has above the minimum version of Windows 10. What gives? I'm use to either building web applications or just building console tools for myself. I figured self-contained would mean just handing over the contents of the publish folder.
I should point out, that the publish folder APPEARS to be correct... its over 230 files in there.
Can you try to publish with these settings?
Step 1:
Step 2: Open your .csproj and add these, or swap with yours.
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net5.0-windows</TargetFramework>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishSingleFile>true</PublishSingleFile>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<UseWPF>true</UseWPF>
// keep other info
</PropertyGroup>
Related
I upgraded Visual Studio Community to the final release, and it stopped working. Specifically, I could generate a new project, but when I try to load it, it gave me an error
Critical Project 'SdkTest' load failed| [MSB4236] The SDK 'Microsoft.NET.Sdk.Web' specified could not be found. ...\SdkTest.csproj
Even though build and run worked fine
I ran "repair" on VS2022, and it seems to be working now from Visual Studio. However, dotnet --info doesn't show any SDKs; only runtime; and dotnet build or dotnet new give an error:
C:\Code>dotnet new console -o myapp
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'new' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I even reinstalled .NET 6 and I see it in the list of applications (along with older SDKs). I checked the path, and I see everything that I expect to see:
C:\Program Files (x86)\dotnet\
C:\Program Files\dotnet\
C:\Users\me\.dotnet\tools
I am running Windows 11.
It's known bug in VS2022 installation.
Problem is that dotnet you access is located inside Program Files(x86)/dotnet, but all sdk's are located in Program Files/dotnet. You simply need to edit PATH environment variable so Program Files/dotnet goes before Program Files(x86)/dotnet. If you don't see Program Files(x86)/dotnet in user environment variable (which is likely to happen) then edit system environment variable (located below)
Example with screenshots: https://stackoverflow.com/a/44272417/10339675
I've been running my ASP.NET Core 2.1 Preview-1 app on Azure since this release became available. I had installed the ASP.NET Core runtime extensions through the portal and it's been working fine.
Now that Microsoft released ASP.NET Core 2.1 Preview-2, I installed the upgrade to the SDK. Updated my Nuget packages so that I have the preview-2 versions of everything. See my csproj file below:
I also removed the ASP.NET Core Runtime extensions from Azure App Service for my app which was showing 2.1 Preview-1. Instead installed ASP.NET Core 2.1 run times for x86 and x64 separately -- see below:
Compiled the app and published it to my Azure App service but I'm getting errors. First I got the 502.5 error. Now, I'm getting:
The specified CGI application encountered an error and the server
terminated the process.
What am I missing here?
UPDATE:
As the answer suggested, I set my target to x86 (to play it safe) -- see below:
I removed the extension and the individual x86 and x64 run times and installed only the x86 with support for ASP.NET Core 2.1 preview-2 -- see below:
I restarted the app several times and I'm still getting 502.5.
I then tried to do a self deploy through CLI command line by issuing the following command:
dotnet publish -c Release -r win10-x64
And I get the following error:
C:\Program
Files\dotnet\sdk\2.1.300-preview2-008530\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(125,5):
error : The RuntimeIdentifier platform 'win10-x64' and the
PlatformTarget 'x86' must be compatible.
Does this mean I have the x86 version of the SDK installed and I must target x86?
I didn't have half the trouble that I'm going through now going from ASP.NET Core 2.0 to 2.1!!!!
UPDATE 2:
Just ran dotnet --info in Kudu console. If I'm reading this correctly, I don't have the correct runtime.
Update 3:
I think this screen shot confirms what I was saying.
Update 4:
I installed x86 version of ASP.NET Core 2.1 Runtime -- see below:
When I run dotnet --info in Kudu console, I get the following which confuses me. I'm still not seeing the version I was expecting to see:
And when I hit the URL, I'm still getting 502.5 and the same message in Kudu console when I run dotnet MyApp.dll telling me that the correct version of the runtime is not found.
How will I get the correct version in there? I thought installing it through the portal would do it.
We've managed to publish ASP.NET Core 2.1 RC1 webapp to Azure app-service using "self-contained" deployment mode.
Platform target: Any CPU
Here are the package references from our .csproj:
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.0-rc1-final" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.AzureAppServicesIntegration" Version="2.1.0-rc1-final" />
The steps I took to get this working:
Remove the 2.1-preview1 ASP.NET Core Runtime Extension.
Check the application settings to see if you're running under 32-bit or 64-bit.
Install only the matching (32- or 64-bit) ASP.NET Core 2.1 Runtime.
Restart the web app.
Restarting is important - before restarting the .NET Core tools were the wrong version and I would also get 502.5 errors.
As you've installed both 32- and 64-bit runtimes I'd try removing the one that your application doesn't need and restart the web app.
I had the same problem. Finally after 2 hours I fixed it.
Here is my configuration:
Extensions:
Console dotnet --info command:
Console kudu dotnet --version command:
a) Remember to restart your app after install extension.
b) Clear your wwwroot folder from old files and publish again.
I got my project working on asp.net core 2.1 Preview 2 on Azure.
I did the following steps;
Deleted the old asp.net core extension from Azure app service Extension
Using kudus deleted all the files in wwwroot folder of the site.
Installed asp.net core site extension from Azure as shown in the picture below and restarted the app service
Before deploying to Azure, the publish configuration option used is as depicted in the picture below,
That's it.
Try adding a global.json file in your project folder with this content:
{
"sdk": {
"version": "2.1.300-preview2-008530"
}
}
Restart your app after that to be on the safe side.
Here's the only thing that seems to have worked for me.
I did a self-contained deployment using
dotnet publish --self-contained -r win10-x64 -c Release
I then had to do a manual deployment -- in my case using FTP.
I really would like this issue to be resolved but if it's not resolved by my next deployment, I'll do the zip deploy. Because my app has a ReactJs frontend, there were thousands of files to deploy and FTP was not a lot of fun!
Because this approach doesn't depend on what's installed or not installed on Azure App Service, it's a much more straight forward solution.
I still want to be able to simply click Publish in Visual Studio though!
UPDATE:
I just did a zip deployment and I'm still getting the errors I was getting before even though zip deployment was successful. So, something is still not right!
I had a problem with a complex website, so I created a simple one with just the App file set at the same version:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />
</ItemGroup>
and then, taken from Tim Diekmann's example, I did nothing apart from changing the Deployment Mode in the Azure publishing configuration Settings to Self-Contained - and that worked.
I wrote a test project using .NET Core and assembled the self-contained deployment for Ubuntu 16.04 as described here (see Self-contained deployment without third-party dependencies).
But when I run the app I get the following error:
An assembly specified in the application dependencies manifest (Test.deps.json) was not found:
package: 'runtime.linux-x64.Microsoft.NETCore.App', version: '2.0.0-preview2-25407-01'
path: 'runtimes/linux-x64/lib/netcoreapp2.0/Microsoft.CSharp.dll'
I am using .NET Core 2.0 Preview 2, VS2017 Preview.
I will be grateful for any help!
This is an old question, but I just ran across this when I was trying to run a .Net Core application on Linux and wanted to share the solution. If you are getting the error above, you are likely trying to execute the wrong binary. For those following along from scratch, follow these steps:
On Windows, open a command prompt in the directory of the project you want to run on Linux.
Build the project for Linux using dotnet publish -r linux-x64
I chose to target linux-x64, but you can target a specific runtime if you'd like. Runtime identifiers can be found here.
Copy the published files to the Linux workstation. Because the above command omitted the configuration flag -c, the configuration defaulted to debug. The published files will be in Debug\netcoreapp2.0\linux-x64\publish
Note: there will be binaries in Debug\netcoreapp2.0\linux-x64\ too. These are not the binaries you want to copy to your Linux workstation. If you run these binaries, you will get the error described in the OP. Copy all the files in the publish directory instead. Ignore whatever files might be in linux-x64.
On the Linux workstation, give execute permission to the binary file. My project was named ConsoleUI, so I used chmod 764 ConsoleUI
Execute the binary using ./ConsoleUI
Keep in mind that you will need to at least have the .Net Core runtime installed on your Linux workstation.
I created a .NET Core application (v1.1) in Visual Studio 2017. When I compile it, I get a DLL file produced instead of the expected EXE file for the built project. I did check the csproj file and confirmed the output type is set to exe, but no dice.
Why is Visual Studio 2017 is still producing a DLL file?
I'm sure it's a quick setting somewhere that I forgot...
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Core.EF.SqlServer\Core.EF.SqlServer.csproj" />
</ItemGroup>
</Project>
Update 2019:
.NET Core 3.0+ projects will now include an executable for the platform you build on by default. This is just a shim executable and your main logic is still inside a .dll file.
But .NET Core 3.0 also introduced single-file deployments so deploying with
dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false
will create a single .exe file containing all your dependencies. You can change --self-contained to true to also include the .NET Core Runtime as well so .NET Core does not need to be installed globally on the target machine.
Original
.NET Core applications are supposed to be .dllfiles. OutputType set to Exe in this case means "executable" and does everything necessary to ensure that the output is runnable (entry point from Main() method, .runtimeconfig.json file). The resulting DLL file is meant to be run using:
dotnet yourapp.dll
This DLL file works across all platforms that are supported by the .NET Core runtime (Windows, Linux, and macOS). This is called a "portable" or "framework dependent" deployment.
If you want really a .exe file, consider self-contained deployments. This will create an output that contains its own copy of the .NET Core runtime and an yourapp.exe file - but it also increases the size of the published application and it needs to be updated when new versions of the runtime are released.
Also, the resulting application only works on the operating system published for.
Refer to .NET Core application deployment for more details on the deployment options and how to set them up.
In Visual Studio 2017:
Right click on your project and select Publish (In Visual Studio 2019, click on menu Build → Publish <projectName>)
Select 'Folder' and create a new profile
In tab 'Publish', click 'Configure...'
Select Deployment Mode: Self-contained, Target Runtime: win-x86 (or win-x64)
Save
Publish
In the folder <Your project>\bin\Debug\netcoreapp2.1\win-x86\ you will see the EXE file:
Starting with .NET Core 2.2 you can build framework-dependent executables
Although building a self-contained deployment can be a good solution, it has its own drawbacks. (See R.Titov and Martin Ullrichs' answers on SCD-s.)
Fortunately, .NET Core 2.2 supports the building of so called framework-dependent executable-s, that are essentially a wrapper binary (.exe on Windows) around the standard dll-s.
This way you have all the advantages (and disadvantages) of the standard framework-dependent deployment (again, see Martin's answer), but you have a convenient way to launch it, without having to call it through the dotnet CLI.
You can publish your app as a Framework-Dependent Executable using the following syntax:
dotnet publish -c Release -r <RID> --self-contained false
Where RID is the usual runtime identifier, e.g. win-x64 or whatever platform you wish to build for (see the catalog here).
That's how you do a self-contained publish with command-line in any OS:
dotnet publish C:\src\App\App.csproj -c release -r win-x64 -o output-win-x64
Besides, you might want to get the output decreased from typical ~60 MB for a simple Hello World app to ~30 MB by using ILLink.
Also, you might want to go further and get a single .exe file of a size at around 5 MB and use ILCompiler. See this reply.
The other answers are good, but what I find sometimes convenient is:
Not have it self-contained because the target machine is likely to have .NET Core of the correct version installed. This cuts on number of the DLL files I need to ship.
Not have to specify dotnet on the command line
For this, a bat file wrapper can be used, similar to these lines:
#ECHO OFF
REM see http://joshua.poehls.me/powershell-batch-file-wrapper/
SET SCRIPTNAME=%~d0%~p0%~n0.dll
SET ARGS=%*
dotnet "%SCRIPTNAME%" %ARGS%
EXIT /B %ERRORLEVEL%
If your application ends up in yourapp.dll, name the bat file yourapp.bat and place it along side the DLL file. Now instead of dotnet yourapp.dll params you can call yourapp params.
Note that the context of this answer is in-house tooling, so all the developers using the utility will have a pretty standard development machine setup. If this is to be distributed to an external customer who is running who knows what on their boxes, the self-contained option is far superior.
We're trying to write ASP.NET applications on a Mac using VSCode. We have successfully installed VSCode, DNX, Yeoman, Node.js and npm, and permutations of everything else mentioned in the ASP.NET guide. After creating a sample application with Yo, restoring dependencies, and even building with no errors, running the application with "dnx web" Returns an error.
System.TypeLoadException: Could not load type 'Microsoft.Extensions.PlatformAbstractions.IAssemblyLoadContextAccessor' from assembly 'Microsoft.Extensions.PlatformAbstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
(Full stack trace)
We get this error specifically when running "dnx web" from the command line or through VSCode's "dnx run command", and both with dnx 1.0.0-rc1-update1 and the latest update (rc2-16595, I believe)
I think this is a versioning problem in our Kestrel setup - our project (dnu build)s properly, just the test breaks while it loads. Any ideas?
I had a same problem above on OS X v10.11.x.
Step 1: Make sure, you run this command:
$ dnvm list
Step 2: Change to the correct version.
E.g on my machine, I changed
$ dnvm use 1.0.0-rc1-update2 -r mono
Good luck!