We have a continuous WebJob that is written in .NET Core 2.x and has been running fine for the past few weeks. Recently someone made some changes to this WebJob and brought in a 3rd party NuGet package. Now, I am unable to start the WebJob because it is unable to locate one of the 3rd Party libraries dependencies.
This is the error message:
D:\local\Temp\jobs\continuous\Temp1\oitdncff.sfg>dotnet Temp1.dll
Error:
An assembly specified in the application dependencies manifest (Temp1.deps.json) was not found:
package: 'System.Drawing.Common', version: '4.5.0-preview1-25914-04'
path: 'runtimes/win/lib/netcoreapp2.0/System.Drawing.Common.dll'
I have tried several things I found whilst Googling this problem. Here is the PropertyGroup and ItemGroup (NuGet packages) from the csproj file:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<ApplicationIcon />
<StartupObject>Temp1.Program</StartupObject>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
<LangVersion>latest</LangVersion>
<Version>1.0.0.0</Version>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
<PackageReference Include="AsyncEnumerator" Version="2.1.0" />
<PackageReference Include="EPPlus.Core" Version="1.5.4" />
<PackageReference Include="Microsoft.ApplicationInsights" Version="2.5.1" />
<PackageReference Include="Microsoft.ApplicationInsights.DependencyCollector" Version="2.5.1" />
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="2.0.0" />
<PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Azure.WebJobs.Logging.ApplicationInsights" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Azure.WebJobs.ServiceBus" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Extensions.Configuration" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.FileExtensions" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Configuration" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.0.0" />
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
</ItemGroup>
Per suggestions online, I added the line
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
and
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
The package in question that has the dependency is EPPlus.Core
I have confirmed that the library System.Drawing.Common does exist in the app folder on our Azure Web App but the when the WebJob starts up, it is ignoring that the file is there and looking in the runtimes (GAC) and failing.
UPDATE:
I realized that the EPPlus.core package was not official so switched over to the official package hoping this would resolve the error. Same error but a new version of the System.Drawing.Common version: 4.5.0-preview1-26216-02
I have manually added the NuGet package for System.Drawing.Common version: 4.5.0-preview2-26406-04 to the project, this removed the original error but then I started getting an error that Microsoft.Win32.SystemEvents version: 4.5.0-preview2-26406-04 could not be found. This library is a dependent of System.Drawing.Common.
I attempted to do the same thing I did above and added the NuGet package for Microsoft.Win32.SystemEvents version: 4.5.0-preview2-26406-04 directly to the project but this time the error is not going away.
FURTHER UPDATE:
After searching more, I came across a posting here that talked about publishing and then zipping up the published directory and uploading the zip. This did actually work, the error in question was gone but this is not really a solution. We are using VSTS as our repo system and our CI/CD. I have the build configration set to do a publish and then copy the files up. The WebJob throws the error when its deployed via this process.
First, I would like to state that as of today, to my knowledge, .NET Core is not 100% supported with Azure WebJobs (feel free to correct me if I am wrong) but there are lots of articles and posts on how to make them work.
Below is the solution I did to get around the above issue I was having and whilst I do not feel this is elegant, I do feel that Microsoft has done something odd that most developers would not think is the correct path.
The reason I was having issues was that when I built (in debug or release) the manifest file was always pointing to the runtimes (GAC). Running locally on my box was never an issue because the files could be found. The oddity is when building in release mode, all files were copied to the bin folder yet the manifest still told the program to look in the runtimes and not to use the local copies. When this was pushed out to the WebJob itself, these files did not exist in the runtime so the WebJob would throw exceptions.
The workaround I had to do is as follows:
dotnet build (Solution - Release Configuration)
dotnet publish (WebJobs Only - Do Not Zip)
dotnet publish (Web Project Only - Do Not Zip)
Copy WebJob Data from Publish to the Web Project directory \App_Data\jobs\continuous\ directory
Zip Up Web Project Published Directory (this is what gets deployed)
My honest opinion is, when I build a webjob project in release mode, the process should transform the manifest to look for any referenced libraries locally before attempting to look for them in the runtimes.
Related
I have a solution created in .NET 6.0 using Visual Studio 2022 which has many projects.
Each project has so many nuget package references in the .csproj file as below.
Is it possible to manage all nuget packages in a single location / globally in the solution (instead of for each project)?
This will make sure all projects in the solution are using the same version of the package (no more version conflicts between the projects for the same nuget package).
Updating the package once at the central location will ensure all projects are referring to the same updated version. No need to update the package for every project.
Thanks for your help.
<ItemGroup>
<PackageReference Include="MediatR.Extensions.Microsoft.DependencyInjection" Version="10.0.1" />
<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.20.0" />
<PackageReference Include="Microsoft.ApplicationInsights.Kubernetes" Version="2.0.2" />
<PackageReference Include="Microsoft.ApplicationInsights.Kubernetes.HostingStartup" Version="2.0.2" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="6.0.1" />
<PackageReference Include="Microsoft.Azure.ServiceBus" Version="5.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.1">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="6.0.0" />
<PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.14.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="6.0.1" />
<PackageReference Include="System.Collections" Version="4.3.0" />
<PackageReference Include="System.Runtime" Version="4.3.1" />
</ItemGroup>
There's a few approaches to doing this. Currently (at the time of this edit), only NuGet's Central Package Version Management supports managing transitive package dependencies.
Manually, with a .targets file
Have a .targets file with all the packages you reference but use <PackageReference Update= instead of Include=. Include this in your Directory.Build.targets file, so that it will be applied at the end of each project file.
The biggest downside to this is that any time a new PackageReference is added to any project, you'll need to also remember to update the .targets file to include an entry to update that package version.
This will ensure that all of your <PackageReference> entries will unify to the same versions. However, it does not impact transitive references, i.e. if you have Project1 -> Package1 -> Package2, but only have a PackageReference to Package1, you won't be able to affect the referenced version of Package2. This may create conflicts if Project2 -> Package2 at a different version than what Package1 references.
Use the Central Package Versions MSBuild SDK (CPV)
The manual process can be error-prone, so there's a 3rd party SDK to help make the process smoother. You can find it at Central Package Versions. This also provides enforcement that users do not specify a version in the project (because they should be using the central one instead!) so it will be more consistent than using the manual technique.
This also does not resolve transitive dependency issues in any way.
Use Nuget Central Package Version Management (CPVM)
This is the NuGet team's solution to the issue. It's explained in this blog post, or you can find the original documentation at Centrally managing NuGet package versions.
Have a file named Directory.Packages.props in your root folder, and enable the feature by adding:
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
Now, similar to the CPV SDK, you should remove all versions from the <PackageReference> elements, and put them in <PackageVersion> elements in your Directory.Packages.props files. If you need to override a version there are two methods:
On the <PackageReference> item, add a VersionOveride=1.2.3.4 attribute.
In the .csproj add <PackageVersion Update="PackageName" Version="DifferentVersion" /> (this is because Directory.Packages.props is imported via the .NET SDKs .props file, which is before the content of the .csproj is evaluated).
This by itself does not help with transitive references. You can additionally add <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled> to enable pinning for transitive packages. What this basically does is to determine if any of your direct or indirect (transitive) PackageReferences has a matching PackageVersion, and if so it promotes that as though it were a direct reference (meaning anything that depends on it will also get the pinned version). Transitive pinning support requires at least NuGet 6.2, VS 2022 17.2, or the .NET SDK 6.0.300.
The new CPM feature was mentioned, but I thought I'd include a full example too.
You could use nuget's new "Central Package Management" feature.
Example problem:
Suppose you have monorepo (i.e. VS "solution" or VSCode "workspace") with multiple projects.
ProjectA.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Baz" Version="1.0.0" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.0.0" />
</ItemGroup>
ProjectB.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Qux" Version="1.2.3" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.5.6" />
</ItemGroup>
Some items are the same whereas others differ. And you need to remember to keep the versions in sync - the example shows that you forgot to do that!
Step 1: remove the versions
ProjectA.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Baz" />
<PackageReference Include="Spam.Ham.Eggs" />
</ItemGroup>
ProjectB.csproj:
<ItemGroup>
<PackageReference Include="Foo.Bar.Qux" />
<PackageReference Include="Spam.Ham.Eggs" Version="4.0.0" /> <!-- note version override for this project -->
</ItemGroup>
Step 2: add file named Directory.Packages.props to your repo's root
<Project>
<PropertyGroup>
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
</PropertyGroup>
<ItemGroup>
<!-- use 'PackageVersion' rather than 'PackageReference' -->
<PackageVersion Include="Foo.Bar.Baz" Version="1.2.3" />
<PackageVersion Include="Foo.Bar.Qux" Version="1.2.3" />
<PackageVersion Include="Spam.Ham.Eggs" Version="4.5.6" />
</ItemGroup>
</Project>
Step 3: restore
For each project:
clear build output: dotnet clean
restore packages: dotnet restore
All your projects will now use the versions you've specified in the config file.
There are more options, like version overrides, and transitive dependency pinining - read the docs for more.
As part of a WebApi app upgrade, I upgraded an Azure function from .Netcore 2 to .Net5. This function has previously worked. When I run the function, I get the following error:
System.Private.CoreLib: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
I made the following changes to the function project as part of the upgrade:
Changed Project file TargetFramework to .net5.0
Changed AzureFunctionsVersion to v3
Upgraded the referenced packages
Microsoft.Azure.WebJobs
Microsoft.Azure.WebJobs.Extensions.EventGrid
Microsoft.Azure.WebJobs.Extensions.Storage
Newtonsoft.Json
I changed the Azure function configuration setting for the Runtime Version to ~3.
After getting the above error, I also added the packages
Microsoft.Extensions.Logging
Microsoft.Extensions.Logging.Abstractions
Building the project with the above references doesn't create the Microsoft.Extensions.Logging.Abstractions.dll in the .Net5 bin directory. Note that I do see that dll in the bin directory of the .Netcore 2 build. Why am I not seeing the dll when building for .Net5?
Functions.csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
<DefineConstants>DEBUG;TRACE</DefineConstants>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.27" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.EventGrid" Version="2.1.0" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="4.0.4" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="5.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="5.0.0" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.12" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\VI.VirtualIncision.Managers\VI.VirtualIncision.Managers.csproj" />
</ItemGroup>
<ItemGroup>
<None Update="appsettings.json">
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
Based on your packages (i.e. Microsoft.Azure.WebJobs) and your csproj file it looks like you are currently running an "in-process Azure Function", and .NET 5 is not supported for these types of Azure Functions, so that is why you are getting that error. So you have 3 options:
Based on this Microsoft blog post, it looks like Microsoft is planning on skipping.NET 5 and just adds support for .NET 6 to in-process Azure functions. So you can just wait for .NET 6.
You can try to switch your Azure Function to be a .NET Isolated Process Function which is more involved than just simply updating some packages and changing the target framework. It requires some major changes to how your project is setup and what nuget packages you are using. Microsoft has a guide around this here: https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide
You can also just downgrade your Microsoft packages to 3.x.x version and keep everything .NET Core 3.1. You will need to make sure you don't have any other dependencies that use .NET 5 packages or else you will see a similar issue.
I have installed VS 2019 on my windows 10.
Created ASP.net Core Web Project -> Selected API.
When I try to generate controller referring the model and created the context class,
It is not generating the controller class but it gives me the following error:
Error,
there was an error running the selected code generator
'Unhandled exception. System.IO.FileNotFoundException: Could not load
file or assembly 'Microsoft.VisualStudio.Web.CodeGeneration.Utils,
Version=3.1.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
The system cannot find the file specified. File name:
'Microsoft.VisualStudio.Web.CodeGeneration.Utils, Version=3.1.2.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60' at
Microsoft.VisualStudio.Web.CodeGeneration.Design.Program.Main(String[]
args)
I also had this problem but the follwing answer worked for me.
Select "Manage Nuget Packages" and install these packages
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration" Version="3.1.2" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.1.2" ExcludeAssets="All" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Utils" Version="3.1.2" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGenerators.Mvc" Version="3.1.2" />
To solve the problem, you can right click on your project, then select Manage Nuget Packages.
Next, Search Microsoft.VisualStudio.Web.CodeGeneratio.Utils, then install it.
After installing the above, It is generating without error.
Please check if you have all the package on compatible version. This could happen when you have packages of different versions, one of which is not supporting the current functionality/project type.
First, check your csproj file. There is no package reference for 'Microsoft.VisualStudio.Web.CodeGeneration.Utils, Version=3.1.2.0'. This is why the error message showing "Could not load file or assembly". Easy to solve. https://www.nuget.org/packages/Microsoft.VisualStudio.Web.CodeGeneration.Utils/
Go to Package Manager Console install it.
For what it's worth, the below solution is what worked for me.
My Setup:
First of all my project setup was different. I had a MyProject.Data and MyProject, and I was trying to scaffold "API Controller with actions, using Entity Framework" on to my API folder in MyProject, and I was getting the error in question. I was using .net 3.1.
Solution:
I had to downgrade all the below nuget packages installed on MyProject.Data project
Before downgrade:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="5.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="5.0.2">
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.2">
After downgrade:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.11" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="3.1.11">
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.11" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="3.1.11">
Then tried again to use scaffolding and it just worked!!
After scaffolding MyProject had the below nuget package versions installed:
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="3.1.11" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.11" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="3.1.11"/>
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="3.1.4" />
The main problem was that no errors were displayed other than the one that shows up on the dialog box or does not even point us to any logs or nor any helpful documentation are available. If anyone finds one please attach it to this answer. It was very frustrating and this almost ate away half-day of my weekend :(
Hope it helps someone. Happy coding!!
I had a .Data project and another another .API project in my solution. The auto scaffolded action controller was trying to add Microsoft.VisualStudio.Web.CodeGeneration.Design which goes up to v5.0.2. I had to downgrade all my nuget packages down to 5.0.2 as follows:
Data Project
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="5.0.2">
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.2">
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.2" />
API project
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="5.0.2">
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.2">
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="5.0.2" />
The API action controller with EF core dbcontext was then able to successfully add:
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="5.0.2" />
I hope this helps! All the best.
I was having a similar behavior, but with a different version of the package: 'Microsoft.VisualStudio.Web.CodeGeneration.Utils, Version=3.1.4.0'.
The package was already installed (both in Manage NUGet Packages and also in .csproj file). I uninstalled it from Manage NUGet Packages and reinstalled.
That solved my issue.
I have also face the same problem. It's a problem with different versions of the NuGet Packages. just try to use similar versions of packages.
Microsoft.VisualStudio.Web.CodeGeneration.Utils(5.0.2)
Microsoft.VisualStudio.Web.CodeGeneration.Design(5.0.2)
I had similar error during ovveride Identity login and register layout.
I did uninstall all package from Application.Web and install again.
My reinstall libraries from NuGet Packages:
Microsoft.AspNetCore.Authentication.Google
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
Microsoft.AspNetCore.Identity.EntityFrameworkCore
Microsoft.AspNetCore.Identity.UI
Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools
Microsoft.VisualStudio.Web.CodeGeneration.Design
My solution had 5 projects (2 dlls, webservice, db and MVC). I removed all but the MVC project and the problem ceased. Added all the projects back in and the problem did not return. Comparing the old solution file to the new one showed a bunch of changes, difficult to say which change was the fix, but the solution file is much cleaner.
In my case, I only update the dependencies for the same version and It Works :)
I Just update al NuGet Packages installed in my project and it run perfectly.
Check and see if you have any warnings about nullable types. If you do, you can update your "ProjectName".csproj and remove the line:
enable
Build the project, and retry.
enter image description here
I'm using ASP.NET Core 2 with Entity Framework Core 2.0.2. I created a context and Add-Migrations command in Package Manager Controller works fine.
However when Update-Database command is used, I get an error:
System.Data.SqlClient is not supported on this platform
I can't figure out where the problem is. Can you help me? Thanks.
My .csproj file:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<DebugType>portable</DebugType>
<PreserveCompilationContext>true</PreserveCompilationContext>
<DockerComposeProjectPath>..\docker-compose.dcproj</DockerComposeProjectPath>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.2.1" />
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.2" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="2.3.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.2" />
</ItemGroup>
</Project>
I ran into the same issue a couple of days ago - I'm not sure what the underlying issue is, but reverting some of the EntityFrameworkCore nuget packages back to 2.0.0 seems to have resolved the issue for me. These are the packages I downgraded:
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.0" />
Same problem here but for me it is a failure on the part of System.Data.SqlClient to load dynamically as part of a plugin. Our plugin dlls are loaded dynamically via Autofac and a controlling service selects the correct one at run time. Unfortunately System.Data.SqlClient will not load dynamically like this, result in the above error message. So I had to load it when the controlling service starts up. This is obviously not ideal but for now it is a usable workaround as all our plugins are still under our control.
I'll be more specific, following a question in comments.
A service selects plug-ins at run time. The plug-ins register their own dependencies via Autofac and if that dependency is a Nuget package they will also include the package as a normal Nuget dependency.
The controlling service registers the plug-in dlls on start up and the first time they are used the plug-in dependencies are also loaded. When System.Data.SqlClient load is attempted following a call to the plug-in that uses SqlClient the "not supported" error results.
Setting System.Data.SqlClient as a Nuget dependency in the controlling service works OK and the library is loaded correctly without error. However, this is not ideal because the the SqlClient library always has to be loaded by the controlling service even if the plug-in selected to run it does not need it.
In other words the SqlClient library is always loaded at service start up occupying resources, etc when it may not even be needed. But at least it works.
I ran into this issue recently with .net standard 2.0 classes being consumed by a regular .net framework app. (.net 4.7.x). The only thing that ultimately fixed my issue was migrating from packages.config to PackageReference on the regular .net app.
Just in case somebody lands here who is trying to run System.Data.SqlClient on net50/netstandard on rid freebsd-x64: Microsoft.Data.SqlClient worked for me.
Maybe this works on every portable option and/or for all System.[...] ->Microsoft.[...] dll.
I spent a couple of hours on this but managed to resolve it. Posting here in case it helps someone else save some time.
In my .csproj files I had
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Removing this solved my problem. Some information can be found here. Setting the value to true causes all dependencies to be copied to the output folder and for me, maybe when loading the application, it was getting confused about which System.Data.SqlClient.dll to load.
I had this exact same issue with a .NET 5.0 console application i was deploying. I discovered that when i published the application the publish profiles target framework was set to 3.1 instead of 5.0 and that is what caused this error for me. After re-publishing with the correct target framework everything worked as expected.
String connectionString, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabaseImpl(String targetMigration, String connectionString, String contextType)
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_0.<.ctor>b__0()
at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Microsoft.Data.SqlClient is not supported on this platform."
go to manage nugget packages and do a downgrade. Hope it works for you
Change the framework to .NetCore 3.x or .NetFramework 4.x...
I've updated my application from ASP.NET Core v1.1 to ASP.NET Core 2.0.
Everything works fine on my dev machine. But when I'm deploying to Azure I get "HTTP Error 502.5 - Process Failure" as a response.
I've activated logging in web.config:
<aspNetCore processPath=".\PublicWeb2.Web.exe" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
The log says:
Failed to initialize CoreCLR, HRESULT: 0x80004005
I get the same error if I run dotnet mysite.dll from the command prompt in Kudo.
The event log in Azure gives the following error:
Application 'MACHINE/WEBROOT/APPHOST/XXXXX' with physical root 'D:\home\site\wwwroot\' failed to start process with commandline 'D:\home\site\wwwroot\XXX ', ErrorCode = '0x80004005 : 80008089.
Relevant Azure settings:
My complete csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
<UserSecretsId>XXXXXXXXXXX</UserSecretsId>
<RuntimeIdentifiers>win7-x86;win7-x64</RuntimeIdentifiers>
<WebProject_DirectoryAccessLevelKey>1</WebProject_DirectoryAccessLevelKey>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MarkdownWeb" Version="1.3.4" />
<PackageReference Include="MarkdownWeb.Git" Version="1.0.1" />
<PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.Cookies" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="2.0.0" />
<PackageReference Include="Microsoft.VisualStudio.Web.BrowserLink" Version="2.0.0" />
<PackageReference Include="System.Net.NameResolution" Version="4.3.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="2.0.0" />
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\XXX\XXX.csproj" />
</ItemGroup>
</Project>
Dotnet version installed on the cloud service:
D:\home\site\wwwroot>dotnet --info
.NET Command Line Tools (2.0.0)
Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9
Runtime Environment:
OS Name: Windows
OS Version: 6.2.9200
OS Platform: Windows
RID: win8-x86
Base Path: D:\Program Files (x86)\dotnet\sdk\2.0.0\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
What I've done (from reading other SO questions):
Added win7-x86 as the first runtime identifier in my csproj
Selected win7-x86 in the azure deployment settings
Manually deleted all old files from wwwroot using the console in Kudo (and then deployed again)
Tried with COREHOST_TRACE=1 activated, but then the console hangs in kudo (and piping to a log doesnt work, i.e. dotnet myapp.dll > mylog.txt)
I have no clue about what to do next.
Finally got it working.
1. Remove runtime identifiers in your project file
In the csproj file of the webproject I removed the <RuntimeIdentifiers> element (it's <RuntimeIdentifier> if you've specified a single runtime).
2. Remove <RuntimeIdentifier> in the publish profile.
The pubxml can be found in solution explorer under
Project -> Properties -> PublishProfiles -> yourfilename.pubxml.
Remove the following line (which got your runtime specified)
<RuntimeIdentifier>win7-x86</RuntimeIdentifier>
Save the file and close it.
Next time you run the publish command, it should say "portable" under the Settings option:
That worked for me.
Thus my guess is that the real solution is:
Stop the site in the azure portal
Remove all old files from the "wwwroot" folder using kudo: https://YOURSITE.scm.azurewebsites.net/DebugConsole, run "rmdir /q /s ." in the wwwroot folder.
Make sure that no RuntimeIdentifier is specified in the publish profile
Make sure that no RuntimeIdentifier is specified in the csproj file
Publish the site
Start the site in the azure portal