service fabric stateless service run netstandard 2.0 error

[zxarcg]

I have created a service fabric application in vs 2017, the only service is a stateless service , and this service is referenced a netstandard 2.0 library . after service is started , the application throw a exception, mainly info as followed: "exception": "System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified. File name: 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' at Stateless1.Stateless1.d2.MoveNext() at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine) at Stateless1.Stateless1.RunAsync(CancellationToken cancellationToken) at Microsoft.ServiceFabric.Services.Runtime.StatelessService.Microsoft.ServiceFabric.Services.Runtime.IStatelessUserServiceInstance.RunAsync(CancellationToken cancellationToken) at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.d18.MoveNext()

Service Fabric Version: 2.7.198

[jahmai-ca]

I'm getting the same. The sfproj Package doesn't seem to copy a large number of dll's from NETStandard across, including netstandard.dll. Manually adding those dll's to the project as items and marking them "Copy Always" does cause them to be copied and the service will run but it's a rabbit hole.

[caserzer]

I got the same issue, the NETSTANDARD dll are missing in pkg folder

[jahmai-ca]

1.txt 2.txt

These files are the difference between the Service.csproj project bin folder and the Deployment.sfproj pkg folder. Not only is netstandard.dll missing on one side, but so are a tonne of other assemblies from the NETStandard.Library.

If I manually copy netstandard.dll into the package, it will at least get to the service boot strap, but then fail with the next missing reference, which for me is System.Runtime.dll.

[caserzer]

The simplest workaround is create a asp.net core empty project, modify the class which inherit the StatelessService

[jahmai-ca]

@caserzer Interesting, I'll try that...

[jahmai-ca]

@caserzer Yep, your suggestion worked perfectly. That should totally be the default template for Stateless/Stateful services!

[vturecek]

@jahmai we're moving in that direction with full .NET Standard 2.0 support soon.

[ToyMakerGR]

@caserzer I did not understand your answer. Could you please elaborate? This also happens to me on a variety of services, right now I have encountered the problem on an Actor SF service. Thank you.

[ThiemeNL]

Same issue here. I added the netstandard nuget to the framework project, and I see that the netstandard dll is in my bin folder. But it is not copied to service fabric pkg folder. So I got the exception.

[gnegno84]

Same issue for me. I've got lot of services and all of them are not working. Expanding the services in the service fabric project shows allo project icons with a yellow triangle. I'am also having issues with System.Net.Http and System.Security.Cryptography.X509Certificates libraries in services. Can't understand why

[tanwarsatya]

Any update on this, I am dealing with same issue after trying to reference a .net standard 2.0 poco class library.

[fleed]

I'm experiencing the same problem. Any update on this?

[dipinbehl]

Cannot refer to any of the standard libraries from within the actor. The code package does not include the netstandard.dll. Any update on when an update could be out? It basically prevents us from using actors in a solution that was build on .net core services and .net standard libraries.

[CRidge]

I had this same problem - a real pain in the neck. What I finally did to fix the malfunctioning actor, was:

I added this to the .sfproj file:

  <Target Name="AfterPackage" AfterTargets="Package">
    <Copy SourceFiles="C:\Program Files\dotnet\sdk\2.0.0\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll" DestinationFolder="$(PackageLocation)\[Actor name]Pkg\Code"/>
  </Target>

This did the trick (for this problem, at least). A simple upgrade of the SF-application in Azure didn't work, but I had the luxuary of being able to delete the applicate completely and reinstall - and then it worked!

[ashishnegi]

@CRidge @dipinbehl @zxarcg how is your actor project references the netstandard assemblies? Can you please share your project files? What is the SF SDK version ?

[ashishnegi]

Also, Can you confirm following :

1. Do you see netstandard.dll and System.Runtime.dll and lot of other dlls in <stateless_csproj_folder>\bin\x64\Debug ?
2. Are these dlls present in <stateless_sfproj_folder\pkg\Debug\<Proect>Pkg\Code ?

Also, What is Visual Studio version number ?

[joakimhew]

@ashishnegi I can confirm that I have the same issue as OP for stateless services. I checked and found the netstandard and runtime DLL's in the bin folder. They are not references in the Code though. My environment is:

Windows 10 Service fabric SDK: 2.8.232 Service fabric runtime: 6.0.232.9494 Visual studio version: 15.5.1

[ravipal]

We are working on this fix and will be addressed in the next VS tooling release.

[mwonger]

Hi Ravikumar, will the fix in the SDK tooling include the copy of the dll system.net.http.dll in addition to netstandard.dll? We ran into the issue with both dlls. much appreciated!

[ravipal]

Yes. With the new behavior the package will include all the files from bin folder of the service project.

[salariamanisha]

I am getting the same error. Is here a workaround till you guys release the fix ?

"Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The sys"

[ashishnegi]

@salariamanisha Copy all the dlls from <stateless_csproj_folder>\bin\x64\Debug to <stateless_sfproj_folder\pkg\Debug\<Proect>Pkg\Code. Please report back if this works or doesn't work.

[GeertvanHorrik]

For us the fix that works is adding this to your package project (sfproj):

  <Target Name="AfterPackage" AfterTargets="Package">
    <Copy SourceFiles="C:\Program Files\dotnet\sdk\2.0.2\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll" DestinationFolder="$(PackageLocation)\MyProject1.ServiceFabricPkg\Code" />
    <Copy SourceFiles="C:\Program Files\dotnet\sdk\2.0.2\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\netstandard.dll" DestinationFolder="$(PackageLocation)\MyProject2.ServiceFabricPkg\Code" />
  </Target>

[GeertvanHorrik]

Here is an even better script, it copies all the output dll's.

Note that you need to add this per service

  <ItemGroup>
    <MyProject1Files Include="$(SolutionDir)\MyProject1.ServiceFabric\bin\x64\$(ConfigurationName)\*.dll" /> 
    <MyProject2Files Include="$(SolutionDir)\MyProject2.ServiceFabric\bin\x64\$(ConfigurationName)\*.dll" />
  </ItemGroup>

  <Target Name="AfterPackage" AfterTargets="Package">
    <Copy SourceFiles="@(MyProject1Files)" DestinationFolder="$(PackageLocation)\MyProject1.ServiceFabricPkg\Code" ContinueOnError="false" />
    <Copy SourceFiles="@(MyProject2Files)" DestinationFolder="$(PackageLocation)\MyProject2.ServiceFabricPkg\Code" ContinueOnError="false" />
  </Target>

[jahmai-ca]

It's worth reiterating that the suggestion in https://github.com/Azure/service-fabric-issues/issues/412#issuecomment-323929697 works perfectly well and doesn't require these project hacks.

[GeertvanHorrik]

@jahmai That sucks a bit if you already have several projects created. Let's just hope this tooling fix comes out real soon so we can leave all this alpha stuff behind us.

[jahmai-ca]

I think we'll find that the fix will be exactly the same as the workaround, only in the default template instead of requiring the one line change.

[ravipal]

Replace the Microsoft.VisualStudio.Azure.Fabric.Application.targets with the attached one in your Microsoft.VisualStudio.Azure.Fabric.MSBuild nuget package. Then set the below property in your *.sfproj. This will package the output folder. \<PackageOutputFolder>true\</PackageOutputFolder>

Microsoft.VisualStudio.Azure.Fabric.Application.zip

[ravipal]

The latest nuget package (1.6.4) has the fix. Please add the property \<PackageOutputFolder>true\</PackageOutputFolder> to *.sfproj to change the package behavior that will include all the files from output folder.

[rexwhitten]

This still occurs when following the new project wizard using Service Fabric SDK 3 + VS 2017 15.5.6 . Which then causes a VS crash, with project files left incomplete.

Only the Service Fabric project is created. No other projects.

[ravipal]

@rexwhitten, This seems like a separate issue. Can you please open a separate issue. Is VS crash reproducible?

[geedsen]

@ravipal My sf packages.config looks like this:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.VisualStudio.Azure.Fabric.MSBuild" version="1.6.4" targetFramework="net47" />
</packages>

The sfproj now starts like this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" InitialTargets=";ValidateMSBuildFiles">
  <Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.4\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.MSBuild.1.6.4\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')" />
  <PropertyGroup Label="Globals">
    <ProjectGuid>6b586ae3-edc5-42ca-895a-bd7a63af5c0c</ProjectGuid>
    <ProjectVersion>2.0</ProjectVersion>
    <MinToolsVersion>1.5</MinToolsVersion>
    <SupportedMSBuildNuGetPackageVersion>1.6.4</SupportedMSBuildNuGetPackageVersion>
    <TargetFrameworkVersion>v4.7</TargetFrameworkVersion>
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
   <PackageOutputFolder>true</PackageOutputFolder>
  </PropertyGroup>

But the problem remains.

[geedsen]

Sorry, apparently I am mixing two topics for a single problem. Let me just continue here . This came from dbreshears @geedsen, what version of VS 2017 from help about? Ensure you have 15.5.6 or 15.6 Preview 4. In Tools->Extensions and updates you should see 2.0.20180124.2 for the "Service Fabric Tools" extension version. Also, whatSDK version do you have of Service Fabric? I would ensure you have the latest 3.0.456 SDK version. After verifying these, you will need to open the .sfproj file and add true, then reload the solution as @ravipal points out. It looks like you have verified already in .sfproj or package.config that Microsoft.VisualStudio.Azure.Fabric.MSBuild = 1.6.4.

[geedsen]

VS and Tools are the same versions as you mention. SDK I was not sure so I installed the version 3.0.456. Problem remains when I deploy to Azure. Works fine btw when deploying to the local cluster. When Deploying to Azure, the code.zip file does not contain the netstandard.dll.

Don't know if this is something, but my SF stateless service project does not have netstandard referenced in the project, should that be?

[ashishnegi]

@abatishchev Is solution in this comment not working for you ? Otherwise, see this comment for workaround and please open a new bug with VS version, SF plugin version and a sample repo project. This might be a regression.

[tastyeggs]

This issue still exists in VS 15.6.7 when I try to deploy a .NET Framework 4.71-based Stateless Service. I had to copy netstandard.dll to my output directory manually from C:\Program Files\dotnet\sdk\2.0.2\Microsoft\Microsoft.NET.Build.Extensions\net461\lib.

[abatishchev]

The only thing worked for me is to switch to net462. I don't get any traction from the dotnetstandard folks.

[tastyeggs]

I wonder if this is because the underlying fabric framework uses .NET 4.6, even though the machine says its on 4.7.2. My understanding is .NET Framework 4.7.2 has built in support for .NET Standard 2.0.

[abatishchev]

To my understanding, this is not SF issue but rather .NET Core, so with the build rather than remote cluster installed runtime: built output doesn't contain the said library. However, since it's getting GAC'd when .NET 4.7.1. is installed, it'd workaround this around and just work.