Microsoft.AspNetCore.All 2.1.1 - asp.net-core

I have a Web Api application targeting NET Core 2.1. When I upgrade the Microsoft.AspNetCore.All nuget package to v2.1.1, the application stops running.
My dotnet:
$ dotnet --version
2.1.300
In my Windows Application event viewer, I first see this warning:
The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\myproj.Logs.HostedApi AppPool is invalid. Static compression is being disabled.
And then I have two of this error:
Log Name: Application
Source: IIS Express AspNetCore Module
Date: 6/21/2018 4:15:11 PM
Event ID: 1000
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CarbonVic
Description:
Application 'MACHINE/WEBROOT/APPHOST/MYPROJ.LOGS.HOSTEDAPI' with physical root 'C:\myproj\Code\myproj-moonshot\apps\myproj.Logs\myproj.Logs.HostedApi\' failed to start process with commandline 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\VSIISExeLauncher.exe -argFile "C:\Users\me\AppData\Local\Temp\tmp27D2.tmp"', ErrorCode = '0x80004005 : 0.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="IIS Express AspNetCore Module" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-06-21T20:15:11.470607900Z" />
<EventRecordID>9844</EventRecordID>
<Channel>Application</Channel>
<Computer>machinename</Computer>
<Security />
</System>
<EventData>
<Data>Application 'MACHINE/WEBROOT/APPHOST/myproj.LOGS.HOSTEDAPI' with physical root 'C:\myproj\Code\myproj-moonshot\apps\myproj.Logs\myproj.Logs.HostedApi\' failed to start process with commandline 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\Web Tools\ProjectSystem\VSIISExeLauncher.exe -argFile "C:\Users\me\AppData\Local\Temp\tmp27D2.tmp"', ErrorCode = '0x80004005 : 0.</Data>
</EventData>
</Event>
Every machine in my shop has this issue. We had to revert back to Microsoft.AspNetCore.All v2.0.8 to make it work again.
Funny thing is: there is no c:\inetpub on any of our machines and there never has been.
Also, I tried to run it on both IISExpress and self-hosted; it will not start with either profile.
Am I missing something here? Anyone know if there's a fix for this?
Help is appreciated always.
V

Well, the good news is that .NET Core 2.1.1 is released now, so you can go and install the new SDK version (2.1.301) from https://dot.net. :)
Now about the issue you had: The meta packages work by referencing the shared framework, which gets installed by the SDK. Since the SDK for 2.1.1 was not installed (2.1.301) your application blew up.
You also mentioned that in the NuGet window the updated packages where already visible. That's true. The individual packages were already released. They just couldn't be resolved because the Microsoft.AspNetCore.All metapackage version 2.1.1 wasn't installed.
On a sidenote: It's recommended to target Microsoft.AspNetCore.App instead of .All . Also the version number can be inferred from the SDK, so you can remove that too.
See: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/metapackage?view=aspnetcore-2.1#migrate

The 2.1.1 release is still in progress. You should use the 2.1.0 packages until it's complete: https://twitter.com/DamianEdwards/status/1009873842662043648.

Related

Where is the Windows App Runtime for V1.1.2 (particularly the DDLM component), please?

NuGet delivered the Microsoft.WindowsAppSDK v1.1.2 yesterday (2022-07-02). My updated WinUI 3 programs now produce the following message when run:
This application requires the Windows App Runtime Version 1.1
(MSIX package version >= 1002.543.1943.0)
I uninstalled previous versions of the runtime and ran the suggested installer (from an elevated PowerShell prompt):
Installing license: MSIX_MAINPACKAGE_LICENSE
Install result : 0x0
Installing license: MSIX_SINGLETONPACKAGE_LICENSE
Install result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.1_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: Microsoft.WindowsAppRuntime.1.1_1000.516.2156.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Deploying package: MicrosoftCorporationII.WinAppRuntime.Main.1.1_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: MicrosoftCorporationII.WinAppRuntime.Singleton_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x6_1000.516.2156.0_x64__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
Deploying package: Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x8_1000.516.2156.0_x86__8wekyb3d8bbwe
Package deployment result : 0x0
Provisioning result : 0x0
All install operations successful.
Although none of the package FullNames included the sought-for version number 1002.543.1943, this was the result:
(get-appxpackage micro*win*appruntime*).packagefullname
Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x86__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Main.1.1_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x6_1000.516.2156.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Singleton_1002.543.1943.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x8_1000.516.2156.0_x86__8wekyb3d8bbwe
All of the components are of the required version except for the DDLM components (note that if you do not run the installer as an administrator, you only get the 1002 version of the principal runtime components. The .Main* and .Singleton* will be _1000.516.2156).
The problem is, the programs are looking for that DDLM module and they both have an MSIX version number of 1000.516.2156.0 (although they also have a dependency on Microsoft.WindowsAppRuntime.1.1_1002.543.1943.0_x??__8wekyb3d8bbwe).
Does anyone know where I can get an MSIX for the 1002.543.1943.0_x?? DDLM component of the runtime? Or a runtime installer that contains all of the components with the required version number?
Thanks for any help.
As of today (2022-07-05), the download links on the official Microsoft page (Downloads for the Windows App SDK) contain all of the correct versions for the latest update (v1.1.2) to the Windows App Runtime.
Just a note: I removed all of my prior installations of the runtime from a PowerShell prompt before running WindowsAppRuntimeInstall.exe. Running (get-appxpackage micro*win*appruntime*).packagefullname reported no packages but trying to install the new runtime still gave me an error (package already installed but has different contents than the installed version). Although I am the only user of this machine, previous installs added the runtime to system accounts.
To see all installations, run (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname from an elevated PowerShell prompt. Look for versions of the runtime with versions of 1002., DDLM.1001, and DDLM.1000. These may be the culprit as they were all in various versions of the runtime installer (v1.1.2) after it first dropped on July 1st. To remove them from all users, run Remove-AppxPackage -AllUsers -PackageName {package full name}. After removing versions that might have been in the "naughty" packages, try running the new WindowsAppRuntimeInstall.exe again. Everything should work.
What I have learned (thanks #aturnbul) is that to ensure a correct framework package update:
Close the WinUI 3 gallery and any other app using the framework.
Using the PowerShell commands listed by aturnbul remove all older packages
Run WindowsAppRuntimeInstall.exe from an elevated command prompt, so you can see any error that it may throw.
Back in PS you can verify that the installation was complete.
// After a failed installation you get only a partial list of packages
PS C:\Windows\system32> (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
// After a successful installation you get all the packages
PS C:\Windows\system32> (get-appxpackage micro*win*appruntime* -AllUsers).packagefullname
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x86__8wekyb3d8bbwe
Microsoft.WindowsAppRuntime.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Main.1.1_1004.584.2120.0_x64__8wekyb3d8bbwe
MicrosoftCorporationII.WinAppRuntime.Singleton_1004.584.2120.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1004.584.2120.0-x6_1004.584.2120.0_x64__8wekyb3d8bbwe
Microsoft.WinAppRuntime.DDLM.1004.584.2120.0-x8_1004.584.2120.0_x86__8wekyb3d8bbwe

Azure Functions: host error has occurred during startup operation Could not load file

I am trying to use Microsoft.AspNetCore.Authentication.Facebook with an Azure functions project. I created a completely clean .net core 3.1 Azure Function project only with the following dependencies:
Microsoft.NET.Sdk.Functions 3.0.7
Microsoft.Azure.Functions.Extensions 1.0.0
Microsoft.AspNetCore.Authentication.Facebook 3.1.5
In the startup file I have the following code:
public override void Configure(IFunctionsHostBuilder builder)
{
facebookOptions.AppId = Environment.GetEnvironmentVariable("Authentication:Facebook:AppId");
facebookOptions.AppSecret = Environment.GetEnvironmentVariable("Authentication:Facebook:AppSecret");
});
When I run the application I get the following error in the console window:
> A host error has occurred during startup operation Could not load file
> or assembly 'Microsoft.AspNetCore.Authentication.Facebook,
> Version=3.1.5.0, Culture=neutral, PublicKeyToken='. The system cannot
> find the file specified.
Any idea what could be wrong?
After I added the user secrets library, debugging stopped working so I spent some time installing different versions of the Azure Functions sdk.
This may only be happening in my project but I decided to share the trial and error summary since this was really time consuming and just in case someone else will be having the same problem.
Microsoft.NET.SDK.Functions version 3.0.5 - 3.0.7
Resulted in the host error has occurred during startup operation Could not load file
Microsoft.NET.SDK.Functions version 3.0.4
Resulted in FunctionsStartup not being called and debugging not triggering
Microsoft.NET.SDK.Functions version 3.0.3
Seems to be working with debugging and no error messages
Version 3.0.3 seems to work so far with debugging and no host error. So I am sticking with this version for now, hopefully it will be resolved in future releases.
Here are the dependencies I have in my solution.
There are two ways to troubleshooting:
Add binding Redirect element in config file.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.AspNetCore.Authentication.Facebook" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="3.1.4" newVersion="3.1.5" />
</dependentAssembly>
</assemblyBinding>
This specifies which version of assembly to use instead of old version. It is not necessarily requires later version be specified in newVersion, earlier version can be provided as well in newVersion.
Update NuGet Package
Update NuGet package in all root project and then in subsequent referred project (if required) where same package is referred.
For more details, you could refer to this article.

AspNetCore.deps.json including runtimes/win/lib/netcoreapp2.1/System.Data.SqlClient.dll reference

I have been chasing an issue with a AspNetCore web api project running on an Azure app service for a few days.
Basically I have a very small api project that when deployed / started - I get a 500.30 ANCM error. Cryptic enough - I pulled the event log from the app service and I find this:
<Data>Could not find inprocess request handler.
Captured output from invoking hostfxr: Error:
An assembly specified in the application dependencies manifest
(SampleApp.Api.deps.json) was not found:
package: 'System.Data.SqlClient', version: '4.6.1'
path: 'runtimes/win/lib/netcoreapp2.1/System.Data.SqlClient.dll'
</Data>
Looking at the SampleApp.deps.json - sure enough I see this:
"runtimeTargets": {
"runtimes/unix/lib/netcoreapp2.1/System.Data.SqlClient.dll": {
"rid": "unix",
"assetType": "runtime",
"assemblyVersion": "4.5.0.1",
"fileVersion": "4.6.27618.1"
},
"runtimes/win/lib/netcoreapp2.1/System.Data.SqlClient.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.5.0.1",
"fileVersion": "4.6.27618.1"
}
},
I have a similar (almost identical) project that is running fine on another app service. If run the
dotnet publish -c release /property:PublishWithAspNetCoreTargetManifest=true
(the same publish command I am running with the app I am having an issue with)
I do not see this section in the runtime targets section at all in the otherapp.deps.json file.
Where is this coming from and how do I get rid of it?
I had a similar situation
a aspnetcore webapp that worked
and a dotnet cli app that failed with an almost identical error as above
What worked for me was running dotnet publish cli-proj -r win-x64. This creates a self-contained bundle, which does not rely on any installed runtime. Then my deployment was taking all the files from bin/debug/netcoreapp3.1/win-x64/publish and pushing them to my webserver.
I'm sure the installed runtime is supposed to supply these files, but it doesn't seem to work well. This "fixed" my issue.
I had a similar issue, where most projects were .Net 5.0 and one class library was .NetStandard, upgrading the .NetStandard Library to .Net 5.0 fixed the issue.
I think the issue is re;ated to not having the correct runtimes for multiple platforms, ideally run with a single platform, or install all the required runtimes.
I forgot to publish the /runtime/ folder when I published on the iis server.
Just ran into the same issue. In my case, the publish profile had target runtime set to win-x64.
Changing this to portable got the publish command to generate the runtime directory and resolve the problem.

Deploy .Net Core as DLL to IIS - Failed to start process with commandline '"dotnet" site.dll'

I have a .Net Core web application targeting net461 Framework. It was originally producing an .EXE and working fine when deploying to IIS. I want to change to a portable app, so I changed "buildOptions" in ProjectJson as follows:
"buildOptions": {
"emitEntryPoint": false,
"preserveCompilationContext": true,
"debugType": "portable"
},
Now when I compile I get a DLL and it runs fine in IIS Express, but when I publish to IIS and change the web.config aspnetcore element to:
<aspNetCore processPath="dotnet" arguments=".\myWebApp.dll"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="false" />
The project fails to run and I see "Failed to start process with commandline '"dotnet" MyWebApp.dll', ErrorCode = '0x80004005'" in the application event log.
Attempting to run from command line with "dotnet mywebapp.dll" results in:
A fatal error was encountered. The library 'hostpolicy.dll' required to
execute the application was not found in 'C:\inetpub\wwwroot\ETimeCore2'.
So I found and copied hostpolicy.dll to the directory and now get:
Could not resolve CoreCLR path. For more details, enable tracing by setting
CORE HOST_TRACE environment variable to 1
I did set the CORE HOST_TRACE to 1 and got a verbose response of all the dlls being loaded with just that one error (above) at the end so it added no value.
Any idea what I am doing wrong?? I prefer a DLL to an EXE because to publish changes when an .EXE, you have to recycle the app pool first which is a real pain.
You cannot use dotnet mywebapp.dll if disable "emitEntryPoint".
emitEntryPoint indicates whether the project is a console application vs. a library. From sources:
if (framework.IsDesktop() && compilerOptions.EmitEntryPoint.GetValueOrDefault())
{
OutputExtension = FileNameSuffixes.DotNet.Exe;
}
In your case the framework.IsDesktop() is true, as your target framework is net461, that is .NET Framework , not .NET Core. That's way you get .exe as output if enable emitEntryPoint.
Actually error "The library 'hostpolicy.dll' required to execute the application was not found in " right now means the following (see http://github.com/dotnet/cli/issues/2859 issue):
dotnet.exe cannot find the entry point in mywebapp.dll

Clearscript files cannot be found on host

Like a lot of others I'm receiving the following error when deploying my ASP.Net MVC application:
Cannot load V8 interface assembly; verify that the following files are installed with your application: ClearScriptV8-32.dll, ClearScriptV8-64.dll, v8-ia32.dll, v8-x64.dll
Clearscript was installed as part of an effort to transform less files on the fly for page requests.
I have tested my application locally in ISS Express and ISS without a hitch.
As suggested here http://clearscript3.rssing.com/chan-14849437/all_p12.html I've also included the missing code libraries as resources to my project.
ClearScriptV8-32.dll, ClearScriptV8-64.dll, v8-ia32.dll, v8-x64.dll are all included in a folder ClearScript.V8 in the bin folder. Removing this folder does not resolve the issue.
At my wits end. Any help is appreciated.
the cause is that asp.net load instantly all libraries in /bin directory.
I added the following rule to ignore Clearscript assemblies, and it worked
<configuration>
<system.diagnostics>
<trace autoflush="true" />
</system.diagnostics>
<system.web>
<compilation>
<assemblies>
<remove assembly="ClearScriptV8-64" />
<remove assembly="ClearScriptV8-32" />
....
</assemblies>
</compilation>
...
To be clear this exception is not always caused by a missing ClearScriptV8-32.dll, ClearScriptV8-64.dll, v8-ia32.dll or v8-x64.dll. Oftentimes the issue is that a dll referenced by one of the aforementioned dlls cannot be found. In cases where the appropriate dlls are on the server installing the appropriate Visual C++ Redistributable will usually solve this transitive dependency issue.
According to the project's discussion forum ClearScript no longer supports Visual Studio 2012. Meaning the version of the Visual C++ Redistributable that needs to be installed on your server is dependent on the version of ClearScript your project is utilizing:
ClearScript Versions 5.0 - 5.3: Visual C++ Redistributable for Visual Studio 2012
ClearScript Versions 5.4 - .....: Visual C++ Redistributable for Visual Studio 2013
Might be a bit late but this may help others coming to this post.
This is a common error when you don't have the Visual C++ Redistributable for Visual Studio 2012 or above installed on the hosting server
http://www.microsoft.com/en-gb/download/details.aspx?id=30679
If you're deploying on Windows Server 2012 with IIS role, there are two things you should do to get ClearScriptV8 running:
As #no1sprite pointed out:
you have to install on the hosting server the Visual C++ Redistributable for Visual Studio 2012 or above:
http://www.microsoft.com/en-gb/download/details.aspx?id=30679
Make sure you place ClearScript.dll in website's bin\ folder, and ClearScriptV8-64.dll and v8-x64.dll into bin\ClearScript.V8.
Optional, for 32-bit applications/platforms:
If you use 32-bit platform, place ClearScriptV8-32.dll and v8-ia32.dll in website's bin\ClearScript.V8\ folder.
Also, In IIS Manager, right-click on site's Application pool and select "Advanced settings...". Set property "Enable 32-bit applications" to true.
This was seconds time starting some project with clearscript v8, and good I remembered what was the issue first time. Loading Native Lib v8.
You would think somewhere in GETTING STARTED or similar topic, devs from ClearScript should have mentioned that you need to have V8 native lib located in subfolders 'ia32' or 'x64' (Platform x86 or Platform x64 respectfully).
Create above subfolders. and place native v8 libs there (32bit into 'ia32', 64bit in 'x64').
I guess they forgot to write down that thought.
just as reminder...
source code taken from loader that helped me last time track the issue...
private static IntPtr LoadNativeLibrary()
{
var suffix = Environment.Is64BitProcess ? "x64" : "ia32";
var fileName = "v8-" + suffix + ".dll";
var messageBuilder = new StringBuilder();
var paths = GetDirPaths().Select(dirPath => Path.Combine(dirPath, deploymentDirName, fileName)).Distinct();
foreach (var path in paths)
{
var hLibrary = NativeMethods.LoadLibraryW(path);
if (hLibrary != IntPtr.Zero)
{
return hLibrary;
}
var exception = new Win32Exception();
messageBuilder.AppendInvariant("\n{0}: {1}", path, MiscHelpers.EnsureNonBlank(exception.Message, "Unknown error"));
}
var message = MiscHelpers.FormatInvariant("Cannot load V8 interface assembly. Load failure information for {0}:{1}", fileName, messageBuilder);
throw new TypeLoadException(message);
}
Oddly enough, this loader should have thrown more meaningful message in debug environment, but it didn't. Instead we have : FileNotFoundException with message "Could not load file or assembly 'ClearScriptV8' or one of its dependencies. The system cannot find the file specified.". Guess there in code elsewhere is another similar loader that actually doesn't use LoadLibrary but falls back to .Net default loader, giving meaningless Exception.
hope this helps others solve similar issues.
None of the answers worked for me. It is a Windows Service application.
Based on accepted answer;
I removed v8-ia32.dll & ClearScriptV8-32.dll (since my application is targeting x64)
It solved the issue.
Posted answers here did not work for me, but this did:
Visual Studio -> Tools -> Options -> Project and Solutions -> Web Projects -> check "Use 64 bit version of IIS Express for web sites and projects"