Skip to content

Could not load ILibraryExport while running HelloMvc sample #515

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
louispellerin opened this issue Apr 30, 2015 · 24 comments
Closed

Could not load ILibraryExport while running HelloMvc sample #515

louispellerin opened this issue Apr 30, 2015 · 24 comments

Comments

@louispellerin
Copy link

Hi,

I've just installed dnvm on my mac using homebrew and when I try to run the HelloMvc sample using "dnu . kestrel", I receive the following error when I try to load http://localhost:5004.

An unhandled exception occurred while processing the request.

TypeLoadException: Could not load type 'Microsoft.Framework.Runtime.Compilation.ILibraryExport' from assembly 'Microsoft.Framework.Runtime.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.Lazy1[System.Collections.Generic.List1[Microsoft.CodeAnalysis.MetadataReference]].CreateValue () [0x00000] in , line 0

Note that I was running the samples with vnext instead of dnx before. I don't know if my attempt to replace the k* things with the new stuff broke something, but the other samples run fine.

Thanks for the help!

@davidfowl
Copy link
Member

Please make sure you are using packages and dnx from the same "train", e.g. beta4 packaged and beta4 dnx etc.

@miguellira
Copy link

@davidfowl I've been trying to get a stable setup of beta4 or later on my Mac ever since upgrading to Mono 4.0.1 but I've been terribly unsuccessful.

My current dnvm list displays the following:

Miguels-MBP:HelloMvc miguellira$ dnvm list
Active Version              Runtime Arch Location             Alias
------ -------              ------- ---- --------             -----
       1.0.0-beta3          mono         ~/.dnx/runtimes      
  *    1.0.0-beta4          mono         ~/.dnx/runtimes      default
       1.0.0-beta5-11649    mono         ~/.dnx/runtimes      
       1.0.0-beta5-11657    mono         ~/.dnx/runtimes   

And I tapped an old bottle of Mono 3.12.1 so my mono --version displays the following:

Miguels-MBP:HelloMvc miguellira$ mono --version
Mono JIT compiler version 3.12.1 (tarball Tue Mar 17 15:03:14 GMT 2015)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
    TLS:           normal
    SIGSEGV:       altstack
    Notification:  kqueue
    Architecture:  amd64
    Disabled:      none
    Misc:          softdebug 
    LLVM:          supported, not enabled.
    GC:            sgen

Pulling down the latest aspnet/Home/ and running dnu restore and dnu build on the 1.0.0-beta4 folder produces the following warning because of a small typo in project.json:

/Users/miguellira/Downloads/Home-dev/samples/1.0.0-beta4/HelloMvc/project.json(17,47): warning: Dependency specified was Microsoft.AspNet.Server.WebListener >= 1.0.0-beta4* but ended up with Microsoft.AspNet.Server.WebListener 1.0.0-beta5-11975.

After updating the project.json file to correctly reference

"Microsoft.AspNet.Server.WebListener": "1.0.0-beta4-*"

I get a successful build, however, running the application results in the known DataProtectionServices issue. aspnet/DataProtection#55

Any idea how I get get my beta4 "train" back on track?

@davidfowl
Copy link
Member

You need mono 4.0.1 to get the fix for the data protection isssue. The home repository has instructions for this. As for getting beta5 bits, You can specify beta4-* but I none of your configured feeds don't have anything beta4 you will get whatever is there that is bigger.

If you want beta4 bits, remove the wild card from your versions and specify beta4 exactly

@miguellira
Copy link

@davidfowl Running Mono 4.0.1 against DNX 4.5.1 results in the System.IO.EndOfStreamException issue that you've already stated has no known workaround (#498) which is why I tapped the previous stable version of Mono (3.12.1).

As far as my configured feeds, I have updated my NuGet.config file to the default in the hopes that I get the most "stable" build(s).

<?xml version="1.0" encoding="utf-8"?>
<configuration />
<!--configuration>
  <packageSources>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/api/v2" />
    <add key="NuGet.org" value="https://nuget.org/api/v2/" />
  </packageSources>
</configuration-->

But even if I update the project.json file to 1.0.0-beta4, restore and build... I still can't successfully run the HelloMvc app.

@Banashek
Copy link

Banashek commented May 1, 2015

I was having the same issue.
Following davidfowl's suggestion did the trick for me.

OS: OSX
Mono: 4.0.1
DNX: v1.0.0-beta4-11566
DNVM: 1.0.0-beta5-10373
DNU: v1.0.0-beta4-11566

Using the samples/1.0.0-beta4/HelloMvc/ directory gave me the ILibraryExport error, but changing the references from "1.0.0-beta4-*" to 1.0.0-beta4" for the dependencies (don't change the version property) fixed the issue.

Looks like even though everything was set to 1.0.0-beta4-, the - was updating to a later dnx version then the one I have? (which is the latest one right now).

Thanks David!

@miguellira
Copy link

@Banashek Can you tell me what your current NuGet feed is set to? I can't seem to install 1.0.0-beta5-10373 of the DNVM to test your exact setup.

I've tried all of the following:

export DNX_FEED=https://www.myget.org/F/aspnetvnext/api/v2
export DNX_FEED=https://www.myget.org/F/aspnetmaster/api/v2
export DNX_FEED=https://www.nuget.org/api/v2

and they all return with the same result:

Miguels-MBP:myWebApp miguellira$ dnvm install 1.0.0-beta5-10373
Default stable feed (https://nuget.org/api/v2) is being overridden by the value of the DNX_FEED variable (https://www.myget.org/F/aspnetvnext/api/v2). 
Downloading dnx-mono.1.0.0-beta5-10373 from https://www.myget.org/F/aspnetvnext/api/v2
Download: https://www.myget.org/F/aspnetvnext/api/v2/package/dnx-mono/1.0.0-beta5-10373
######################################################################## 100.0%
dnx-mono.1.0.0-beta5-10373 was not found in repository https://www.myget.org/F/aspnetvnext/api/v2 
This is most likely caused by the feed not having the version that you typed. Check that you typed the right version and try again. Other possible causes are the feed doesn't have a DNX of the right name format or some other error caused a 404 on the server

Again, for the record, I am able to run dnu build without any errors, however, running dnx . kestrel results in a runtime error against the most basic MVC app.

@Banashek
Copy link

Banashek commented May 1, 2015

% nuget sources
Registered Sources:

  1.  AspNetVNext [Enabled]
      https://www.myget.org/F/aspnetvnext/api/v2
  2.  NuGet.org [Enabled]
      https://nuget.org/api/v2/
  3.  https://www.nuget.org/api/v2/ [Disabled]
      https://www.nuget.org/api/v2/

The dnvm version shouldn't really matter, it's really the dnx and mono versions that seem important.
To my understanding the DNVM just grabs different DNX versions like ruby's rvm.

Have you tapped back to 4.0.1 Mono and double checked the project.json to make sure that the dependencies are correct?

I had the exact same error you posted originally about and the only change needed to solve it was editing the package.json as davidfowl noted.

Here's my current project.json:

{
    "version": "1.0.0-*",
    "webroot": "wwwroot",
    "exclude": [
        "wwwroot"
    ],
    "packExclude": [
        "**.kproj",
        "**.user",
        "**.vspscc"
    ],
    "dependencies": {
        "Kestrel": "1.0.0-beta4",
        "Microsoft.AspNet.Diagnostics": "1.0.0-beta4",
        "Microsoft.AspNet.Mvc": "6.0.0-beta4",
        "Microsoft.AspNet.Server.IIS": "1.0.0-beta4",
        "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4"
    },
    "commands": {
        "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5001",
        "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
    },
    "frameworks": {
         "dnx451": { },
         "dnxcore50": { }
    }
}

@miguellira
Copy link

@Banashek Yes, I tapped back to 4.0.1 but running dnu build on the project.json you posted results in the same System.IO.EndOfStreamException I ran into when I first updated Mono 4.0.1 (#498)

@davidfowl
Copy link
Member

@Banashek
Copy link

Banashek commented May 1, 2015

@miguellira ah ok yeah I seem to get the same error when building. I was just looking at running locally.

Here is my stack trace for anyone interested:

System.IO.EndOfStreamException: Failed to read past end of stream.
  at System.IO.BinaryReader.ReadChar () [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CvtResFile.ReadStringOrID (System.IO.BinaryReader fhIn) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CvtResFile.ReadResFile (System.IO.Stream stream) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.MakeWin32ResourceList (System.IO.Stream win32Resources, Microsoft.CodeAnalysis.DiagnosticBag diagnostics) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.SetupWin32Resources (Microsoft.CodeAnalysis.CSharp.Emit.PEModuleBuilder moduleBeingBuilt, System.IO.Stream win32Resources, Microsoft.CodeAnalysis.DiagnosticBag diagnostics) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.CompileImpl (Microsoft.CodeAnalysis.Emit.CommonPEModuleBuilder moduleBuilder, System.IO.Stream win32Resources, System.IO.Stream xmlDocStream, Boolean generateDebugInfo, Microsoft.CodeAnalysis.DiagnosticBag diagnostics, System.Predicate`1 filterOpt, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.Compile (Microsoft.CodeAnalysis.Emit.CommonPEModuleBuilder moduleBuilder, System.IO.Stream win32Resources, System.IO.Stream xmlDocStream, Boolean generateDebugInfo, Microsoft.CodeAnalysis.DiagnosticBag diagnostics, System.Predicate`1 filterOpt, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.Emit (Microsoft.CodeAnalysis.EmitStreamProvider peStreamProvider, Microsoft.CodeAnalysis.EmitStreamProvider pdbStreamProvider, Microsoft.CodeAnalysis.EmitStreamProvider xmlDocumentationStreamProvider, Microsoft.CodeAnalysis.EmitStreamProvider win32ResourcesStreamProvider, IEnumerable`1 manifestResources, Microsoft.CodeAnalysis.Emit.EmitOptions options, Microsoft.CodeAnalysis.CodeGen.CompilationTestData testData, System.Func`1 getHostDiagnostics, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.Emit (System.IO.Stream peStream, System.IO.Stream pdbStream, System.IO.Stream xmlDocumentationStream, System.IO.Stream win32Resources, IEnumerable`1 manifestResources, Microsoft.CodeAnalysis.Emit.EmitOptions options, Microsoft.CodeAnalysis.CodeGen.CompilationTestData testData, System.Func`1 getHostDiagnostics, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
  at Microsoft.CodeAnalysis.Compilation.Emit (System.IO.Stream peStream, System.IO.Stream pdbStream, System.IO.Stream xmlDocumentationStream, System.IO.Stream win32Resources, IEnumerable`1 manifestResources, Microsoft.CodeAnalysis.Emit.EmitOptions options, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
  at Microsoft.Framework.Runtime.Roslyn.RoslynProjectReference.EmitAssembly (System.String outputPath) [0x00000] in <filename unknown>:0
  at Microsoft.Framework.PackageManager.ProjectBuilder.Build (System.String name, System.String outputPath) [0x00000] in <filename unknown>:0
  at Microsoft.Framework.PackageManager.BuildContext.Build (System.Collections.Generic.List`1 diagnostics) [0x00000] in <filename unknown>:0
  at Microsoft.Framework.PackageManager.BuildManager.Build () [0x00000] in <filename unknown>:0
  at Microsoft.Framework.PackageManager.Program+<>c__DisplayClass3_4.<Main>b__8 () [0x00000] in <filename unknown>:0
  at Microsoft.Framework.Runtime.Common.CommandLine.CommandLineApplication.Execute (System.String[] args) [0x00000] in <filename unknown>:0
  at Microsoft.Framework.PackageManager.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0

I'm not too familiar with these stack traces, but I'll look at them later and respond if I figure it out.

@miguellira
Copy link

@Banashek Well at least I don't feel so alone :-)

As for this error, it has already been logged (#498) and @davidfowl has already confirmed there is no known workaround.

That said, some people do appear to have a healthy Mono 4.0.1/DNX 4.5.1/Beta4 setups: http://tattoocoder.azurewebsites.net/vscode-creating-an-application-with-yeoman-aspnet-generators/

I just wished I was one of them :-(

@Banashek
Copy link

Banashek commented May 1, 2015

As David says in his article posted on this thread "living on the bleeding edge will hurt".

I'm sure things will get better with time.

For now, you could boot up a linux vm and copy the code over if you really need to build out the projects.

Right now I'm not really deploying anywhere, just testing the waters with VSCode and the shiny new tools we got in the last couple days. Luckily the local webserver works so I can do this.

Thanks for linking the existing error @miguellira.

@davidfowl
Copy link
Member

@miguellira can you try running without building?

@miguellira
Copy link

@davidfowl OMG! I can't believe I just didn't tried that. I figured I had to green light the build before running. It works! (well kinda)... I run into the FileSystemWatcher issue (#508) but setting the following fixes that:

export MONO_MANAGED_WATCHER=disabled

screen shot
Thanks!

@TomSchillemans
Copy link

I apparently have DNX 1.0.0-beta5 however my dependancies are on beta4.
I have mono 4.0.1. But I still get this same error. Does it have to do something with DNX beta5? and when I do dnvm install 1.0.0-beta4 I get an error:

Downloading dnx-mono.1.0.0-beta4 from https://nuget.org/api/v2
Download: https://nuget.org/api/v2/package/dnx-mono/1.0.0-beta4
######################################################################## 100.0%
HTTP Error 301 fetching dnx-mono.1.0.0-beta4 from https://nuget.org/api/v2

@davidfowl
Copy link
Member

@TomSchillemans yes that was known issue with dnvm, run dnvm update-self and do it again.

@Gutek
Copy link

Gutek commented May 1, 2015

@davidfowl you can't do update-self on mac... aspnet/dnvm#246

@miguellira
Copy link

@TomSchillemans As @davidfowl mentioned, the HTTP 301 is a redirect error. You can temporarily get around that by setting this value before installing running dmvm install 1.0.0-beta4

export DNX_FEED=https://www.nuget.org/api/v2

As for dnvm update-self, it appears the default installation is /usr/local/Cellar/dnvm/ since it is installed via Homebrew yet that command expects it to be alongside the DNX namely ~/.dnx/dnvm.

@Gutek what is your current dnvm version? Even if it did work it appears it will simply pull down the latest dnvm.sh from https://raw.githubusercontent.com/aspnet/Home/dev/dnvm.sh which is currently 1.0.0-beta-10373

In any event, I did some more research it appears those familiar with OmniSharp's generator-aspnet have been aware of these Mono issues for a few days now (OmniSharp/generator-aspnet#140) and (OmniSharp/generator-aspnet#138).

At this point I really wished @spboyer would tell us how he was able to successfully run dnu build on his Mono/DNX/Beta 4 combination.

@TomSchillemans
Copy link

I added the export and now when I want to use the install I get

dnvm use 1.0.0-beta4
Cannot find dnx-mono.1.0.0-beta4, do you need to run 'dnvm install 1.0.0-beta4'?

However, dnvm list does show 1.0.0-beta4

@Gutek
Copy link

Gutek commented May 1, 2015

yep its showing even without export, its added there after download, but you can't switch to it.

@miguellira
Copy link

@TomSchillemans and @Gutek Can you remove it and then try to reinstall?

rm -rf ~/.dnx/runtimes/dnx-mono.1.0.0-beta4
export DNX_FEED=https://www.nuget.org/api/v2
dmvm install 1.0.0-beta4

The directory gets created prior to the failed download.

@spboyer
Copy link

spboyer commented May 1, 2015

@miguellira (OmniSharp/generator-aspnet#138) - states how we were getting the applications to run under beta4. You will still get the EndOfStream errors on dnu build but the applications will run under dnx . kestrel

1.0.0-beta4 is the stable.

Active Version              Runtime Arch Location             Alias
------ -------              ------- ---- --------             -----
                            mono         ~/.dnx/runtimes
  *    1.0.0-beta4          mono         ~/.dnx/runtimes      default
       1.0.0-beta5-11624    mono         ~/.dnx/runtimes
       1.0.0-beta5-11649    mono         ~/.dnx/runtimes

The steps I took to get it resolved.

$ brew uninstall dnvm
$ brew update
$ brew install dnvm
$ dnvm use default

@miguellira
Copy link

@spboyer thanks for responding. I am currently at that working state. Your excellent write up, however, does not mention this caveat so I was assuming you weren't experiencing any issues at all. Again, thanks for clarifying.

Hopefully a future release of Mono addresses these build issues.

Perhaps the OS X portion of the docs should have some sort of disclaimer or list of known issues.

@TomSchillemans
Copy link

@miguellira This did the trick for me. For some reason I now can use dmx . kestrel from my actual command line now and not get an command not found error. When I start kestrel from VSCode I still get this LibraryExport error. But when running the command from command line, it now works!

@ghost ghost locked as resolved and limited conversation to collaborators Dec 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants