Sdk: Assembly not found: Microsoft.CSharp

[tmds]

After publishing my .net web app throws an exception when I try to start it:

Error: assembly specified in the dependencies manifest was not found -- package: 'Microsoft.CSharp', version: '4.0.1-rc3-24209-08', path: 'lib/netstandard1.3/Microsoft.CSharp.dll'

I use the 'latest' cli from github dotnet/cli on Debian 8.2: 1.0.0-preview2-003032

This seems to be the same issue @GuardRex has: https://github.com/dotnet/cli/issues/3379

I am using the https://www.myget.org/F/aspnetcidev/api/v3/index.json feed. My dependencies in project.json are -rc3-*. I use the same dotnet version to publish and start the application.

In the dotnet folder, there is a Microsoft.CSharp.dll at ./shared/Microsoft.NETCore.App/1.0.0-rc3-004449-00/Microsoft.CSharp.dll.

[guardrex]

My app worked for a few days and has regressed back to ...

Error: assembly specified in the dependencies manifest was not found -- 
package: 'Microsoft.CSharp', version: '4.0.1-rc3-24209-08', 
path: 'lib/netstandard1.3/Microsoft.CSharp.dll'

on the aspnetvnext feed. It's a vanilla portable app ...

"dependencies": {
    "Microsoft.AspNetCore.Diagnostics": "1.0.0-*",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0-*",
    "Microsoft.Extensions.Logging.Console": "1.0.0-*",
    "Microsoft.AspNetCore.StaticFiles": "1.0.0-*",
    "Microsoft.AspNetCore.Mvc": "1.0.0-*",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.0-*",
    "Microsoft.NETCore.App": {
        "type": "platform",
        "version": "1.0.0-*"
    }
},
"frameworks": {
    "netcoreapp1.0": {}
},

Even if I convert it to an rc2-final app on a NuGet feed, I get the same issue, except it asks for a different version ...

Error: assembly specified in the dependencies manifest was not found -- 
package: 'Microsoft.CSharp', version: '4.0.1-rc2-24027', 
path: 'lib/netstandard1.3/Microsoft.CSharp.dll'

... and attempting to supply a dep for the package has no effect.

.NET Command Line Tools (1.0.0-preview2-003032)

Product Information:
 Version:            1.0.0-preview2-003032
 Commit SHA-1 hash:  a3447617f9

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[schellap]

The following is the project.json:

    "dependencies": {
       "Microsoft.NETCore.App": {
         "type": "platform",
         "version": "1.0.0-rc3-*"
       },
       "Newtonsoft.Json": "9.0.1-beta1"
     }

We would expect that, dotnet build produces “App.deps.json” with FX’s runtime assemblies filtered out (trimming). But FX’s runtime assemblies are explicitly listed in the “App.deps.json”.

See link: http://pastebin.com/gDjdFby6

      "Microsoft.CSharp/4.0.1-rc3-24210-06": {
        "dependencies": {
          ...
          "System.Threading": "4.0.11-rc3-24210-06"
        },

        "runtime": {
          "lib/netstandard1.3/Microsoft.CSharp.dll": {}
        }

      "Microsoft.NETCore.App/1.0.0-rc3-004449-00": {
        "dependencies": {
          "Libuv": "1.9.0-rc2-21014",
          "Microsoft.CSharp": "4.0.1-rc3-24210-06",

However, dotnet publish doesn’t use the same semantics (i.e., it trims) as build (i.e., no trimming) – it does not copy the runtime assemblies listed in the application’s “App.deps.json” into the app-base because these dependencies are platform assemblies.

If the app is published in such a manner and moved to a box with RC4 framework (instead of app’s RC3 dependency) installed, then the CSharp.dll reference present in the “App.deps.json” will not be found in the FX directory (because FX has a different version of the CSharp.dll) and also in the app base (because publish trimmed it) erroring out.

Build and publish should be consistent with trimming of runtime, native, resources assemblies if they do/don't do so.

Cc @brthor @eerhardt @piotrpMSFT @anurse @pakrym @davidfowl

[gkhanna79]

@piotrpMSFT marking this for preview2 - move it out if you feel it does not meet the bar.

[gkhanna79]

CC @Petermarcu

[tmds]

@schellap is there a way to workaround the issue e.g. by fixing some dependencies? Which dependencies should be fixed?

If the app is published in such a manner and moved to a box with RC4 framework (instead of app’s RC3 dependency) installed, then the CSharp.dll reference present in the “App.deps.json” will not be found in the FX directory (because FX has a different version of the CSharp.dll) and also in the app base (because publish trimmed it) erroring out.

The issue also occurs when using the same dotnet version on the publish and production machine.

[schellap]

The fix in dotnet build would be to remove the "runtime" section entry for Microsoft.CSharp.dll in the application's .deps.json.

OR

Similarly, like dotnet publish, copy the Microsoft.CSharp.dll from the shared\Microsoft.NETCore.App\1.0.0-rc3-004340\Microsoft.CSharp.dll into the app base.

[tmds]

@schellap apparently I need to do this for quite a number of assemblies... looking forward to a fix :D

[schellap]

@tmds, you can also make sure the exact version (instead of -rc3-*) in the project.json is installed at DOTNET_ROOT\shared\Microsoft.NETCore.App\{project-json-version}

[brthor]

The workaround here is to target the exact version of the SharedFramework that is provided in the sdk you are using to dotnet build your app.

This only occurs in roll-forward scenarios when you are targetting an earlier version of the SharedFX than is available in the sdk you are using for dotnet build

[guardrex]

<sarcasm>... or just go with self-contained, which has been rock-solid</sarcasm> :smile:

I'm glad this one will get addressed ... this isn't the first time we've seen mismatch issues between the shared framework and deps listed in the app, and it was painful the last time, too, but it might be a related issue: https://github.com/dotnet/cli/issues/2454

[TheRealPiotrP]

@pakrym you are working on a related issue. Can you and @livarcocc sync to see if your fix will address this one as well? Also, what is that issue number?

[pakrym]

@piotrpMSFT I think my change will fix this issue as well.

[TheRealPiotrP]

@pakrym let me know if we can help. It would be great to get a first pass at this change today... it'll probably be a bit destabilizing.

[eerhardt]

This is now fixed with dotnet/cli#3574.