FileNotFoundException: [TEMPORARY EXCEPTION MESSAGE] FileLoadErrorGeneric: NLog on build #2619

Closed
perlun opened this Issue Jan 30, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@perlun

perlun commented Jan 30, 2017

I get this error when trying to build my app with CoreRT, using RyuJIT:

$ dotnet build /t:LinkNative
Microsoft (R) Build Engine version 15.1.458.808
Copyright (C) Microsoft Corporation. All rights reserved.


  Unhandled Exception: Internal.TypeSystem.TypeSystemException+FileNotFoundException: [TEMPORARY EXCEPTION MESSAGE] FileLoadErrorGeneric: NLog
     at ILCompiler.CompilerTypeSystemContext.GetModuleForSimpleName(String simpleName, Boolean throwIfNotFound)
     at ILCompiler.CompilerTypeSystemContext.ResolveAssembly(AssemblyName name, Boolean throwIfNotFound)
     at Internal.TypeSystem.Ecma.EcmaModule.ResolveAssemblyReference(AssemblyReferenceHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.EcmaObjectLookupHashtable.CreateValueFromKey(EntityHandle handle)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.CreateValueAndEnsureValueIsInTable(TKey key)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.GetOrCreateValue(TKey key)
     at Internal.TypeSystem.Ecma.EcmaModule.GetObject(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.ResolveTypeReference(TypeReferenceHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.EcmaObjectLookupHashtable.CreateValueFromKey(EntityHandle handle)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.CreateValueAndEnsureValueIsInTable(TKey key)
     at Internal.TypeSystem.LockFreeReaderHashtable`2.GetOrCreateValue(TKey key)
     at Internal.TypeSystem.Ecma.EcmaModule.GetObject(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaModule.GetType(EntityHandle handle)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseType(SignatureTypeCode typeCode)
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseType()
     at Internal.TypeSystem.Ecma.EcmaSignatureParser.ParseFieldSignature()
     at Internal.TypeSystem.Ecma.EcmaField.InitializeFieldType()
     at Internal.TypeSystem.Ecma.EcmaField.get_FieldType()
     at ILCompiler.Metadata.Transform`1.InitializeFieldDefinition(FieldDesc entity, Field record)
     at ILCompiler.Metadata.EntityMap`2.GetOrCreate[TConcreteEntity,TConcreteRecord](TConcreteEntity entity, Action`2 initializer)
     at ILCompiler.Metadata.Transform`1.HandleFieldDefinition(FieldDesc field)
     at ILCompiler.Metadata.Transform`1.InitializeTypeDef(MetadataType entity, TypeDefinition record)
     at ILCompiler.Metadata.EntityMap`2.Create[TConcreteEntity,TConcreteRecord](TConcreteEntity entity, Action`2 initializer)
     at ILCompiler.Metadata.Transform`1.HandleType(TypeDesc type)
     at ILCompiler.Metadata.MetadataTransform.Run[TPolicy](TPolicy policy, IEnumerable`1 modules)
     at ILCompiler.MetadataGeneration.EnsureMetadataGenerated()
     at ILCompiler.MetadataGeneration.GetMetadataBlob()
     at ILCompiler.DependencyAnalysis.MetadataNode.GetData(NodeFactory factory, Boolean relocsOnly)
     at ILCompiler.DependencyAnalysis.ObjectWriter.EmitObject(String objectFilePath, IEnumerable`1 nodes, NodeFactory factory)
     at ILCompiler.RyuJitCompilation.CompileInternal(String outputFile)
     at ILCompiler.Compilation.ILCompiler.ICompilation.Compile(String outputFile)
     at ILCompiler.Program.Run(String[] args)
     at ILCompiler.Program.Main(String[] args)
  /var/folders/2p/f5tb9h_j15ngqjdpdkmwrd_00000gn/T/tmpfaecb9d884cd49c1a830ffb964bc521a.exec.cmd: line 2: 15388 Abort trap: 6           "/Users/plundberg/git/perlun/corert/bin/Product/OSX.x64.Debug/packaging/publish1/corerun" "/Users/plundberg/git/perlun/corert/bin/Product/OSX.x64.Debug/packaging/publish1/ilc.dll" @"native/zup.ilc.rsp"
/Users/plundberg/git/perlun/corert/bin/Product/OSX.x64.Debug/packaging/publish1/Microsoft.NETCore.Native.targets(110,5): error MSB3073: The command ""/Users/plundberg/git/perlun/corert/bin/Product/OSX.x64.Debug/packaging/publish1/corerun" "/Users/plundberg/git/perlun/corert/bin/Product/OSX.x64.Debug/packaging/publish1/ilc.dll" @"native/zup.ilc.rsp"" exited with code 134. [/Volumes/extra/git/perlun/zup/zup.csproj]

The contents of the bin/Debug/netcoreapp1.0/ folder is this; I presume the NLog.dll would have to be included in that folder for it to work:

$ ls -l bin/Debug/netcoreapp1.0/
total 56
-rwxrw-r-- 1 plundberg staff 24649 Jan 30 09:07 zup.deps.json
-rwxrw-r-- 1 plundberg staff 15872 Jan 30 09:07 zup.dll
-rwxrw-r-- 1 plundberg staff  3144 Jan 30 09:07 zup.pdb
-rwxrw-r-- 1 plundberg staff   108 Jan 30 09:13 zup.runtimeconfig.dev.json
-rwxrw-r-- 1 plundberg staff   118 Jan 30 09:13 zup.runtimeconfig.json

This is the contents of my .csproj file:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <DebugType>portable</DebugType>
    <AssemblyName>zup</AssemblyName>
    <OutputType>Exe</OutputType>
    <PackageTargetFallback Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">$(PackageTargetFallback);dnxcore50</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
    <EmbeddedResource Include="compiler\resources\**\*" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="NLog">
      <Version>5.0.0-beta04</Version>
    </PackageReference>
  </ItemGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'netcoreapp1.0' ">
    <PackageReference Include="Microsoft.NETCore.App">
      <Version>1.1.0</Version>
    </PackageReference>
  </ItemGroup>

  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <DefineConstants>$(DefineConstants);RELEASE</DefineConstants>
  </PropertyGroup>

  <Import Project="$(IlcPath)\Microsoft.NETCore.Native.targets" />
</Project>
@jkotas

This comment has been minimized.

Show comment
Hide comment
@jkotas

jkotas Jan 30, 2017

Member

I presume the NLog.dll would have to be included in that folder for it to work

Correct. Microsoft.NETCore.Native.targets does not pick up package references yet. You can try working around this by explicitly adding the NLog.dll via <IlcReference Include="...path to NLog.dll ..." />.

Member

jkotas commented Jan 30, 2017

I presume the NLog.dll would have to be included in that folder for it to work

Correct. Microsoft.NETCore.Native.targets does not pick up package references yet. You can try working around this by explicitly adding the NLog.dll via <IlcReference Include="...path to NLog.dll ..." />.

@perlun

This comment has been minimized.

Show comment
Hide comment
@perlun

perlun Jan 30, 2017

You can try working around this by explicitly adding the NLog.dll via .

Thanks! Something like ~/.nuget/packages/NLog/5.0.0-beta04/lib/netstandard1.5/NLog.dll? Feels quite kludgy, but I can try - thanks. Will report here if I get it working or not.

perlun commented Jan 30, 2017

You can try working around this by explicitly adding the NLog.dll via .

Thanks! Something like ~/.nuget/packages/NLog/5.0.0-beta04/lib/netstandard1.5/NLog.dll? Feels quite kludgy, but I can try - thanks. Will report here if I get it working or not.

@jkotas

This comment has been minimized.

Show comment
Hide comment
@jkotas

jkotas Jan 30, 2017

Member

Something like ~/.nuget/packages/NLog/5.0.0-beta04/lib/netstandard1.5/NLog.dll ?

Yes.

Feels quite kludgy,

Agree. The right fix is to use the package implementation references in Microsoft.NETCore.Native.targets. It requires some reverse engineering of the msbuild scripts, but it should not be that hard.

Member

jkotas commented Jan 30, 2017

Something like ~/.nuget/packages/NLog/5.0.0-beta04/lib/netstandard1.5/NLog.dll ?

Yes.

Feels quite kludgy,

Agree. The right fix is to use the package implementation references in Microsoft.NETCore.Native.targets. It requires some reverse engineering of the msbuild scripts, but it should not be that hard.

@allquixotic

This comment has been minimized.

Show comment
Hide comment
@allquixotic

allquixotic Jul 15, 2017

This issue was filed quite a while ago -- we're a couple months beyond .NET Native's public announcement turning 3 years old, Is this important feature planned soon? I have not yet been able to develop any significant project in .NET with zero third-party dependencies, and I imagine I'm not alone in that; so does the inability to create .NET native builds that include others' code means that the platform is not ready for use even by "early adopters" (3 years later...) at this point?

This issue was filed quite a while ago -- we're a couple months beyond .NET Native's public announcement turning 3 years old, Is this important feature planned soon? I have not yet been able to develop any significant project in .NET with zero third-party dependencies, and I imagine I'm not alone in that; so does the inability to create .NET native builds that include others' code means that the platform is not ready for use even by "early adopters" (3 years later...) at this point?

@jkotas

This comment has been minimized.

Show comment
Hide comment
@jkotas

jkotas Jul 16, 2017

Member

inability to create .NET native builds that include others' code

The workaround above is ugly, but easy to do - it is what we have been using to compile projects with references to other projects or packages. I believe @nattress has a fix for this issue, he just did not have a chance to submit it.

the platform is not ready for use even by "early adopters" (3 years later...)

If you expect preview quality, it is not ready. We have not released preview release yet. Yes, it is taking longer than we would wish - other projects are higher priority.

Member

jkotas commented Jul 16, 2017

inability to create .NET native builds that include others' code

The workaround above is ugly, but easy to do - it is what we have been using to compile projects with references to other projects or packages. I believe @nattress has a fix for this issue, he just did not have a chance to submit it.

the platform is not ready for use even by "early adopters" (3 years later...)

If you expect preview quality, it is not ready. We have not released preview release yet. Yes, it is taking longer than we would wish - other projects are higher priority.

@perlun

This comment has been minimized.

Show comment
Hide comment
@perlun

perlun Jul 17, 2017

@jkotas Understandable, priorities are hard. I think we are some people who ❤️ .NET programming and would find it great to be able to use CoreRT to ship our stuff. I guess we'll just have to wait a few more years. 😉 (or, better yet: to volunteer our time to help CoreRT succeed!)

perlun commented Jul 17, 2017

@jkotas Understandable, priorities are hard. I think we are some people who ❤️ .NET programming and would find it great to be able to use CoreRT to ship our stuff. I guess we'll just have to wait a few more years. 😉 (or, better yet: to volunteer our time to help CoreRT succeed!)

@MichalStrehovsky

This comment has been minimized.

Show comment
Hide comment
@MichalStrehovsky

MichalStrehovsky Jul 17, 2017

Member

we're a couple months beyond .NET Native's public announcement turning 3 years old

Just to point out what may not be obvious: the .NET Native that was announced 3 years ago was .NET Native for Windows Store apps. This has shipped about a year after the announcement and is the shipping story for Windows Store apps in Visual Studio 2015/2017.

Member

MichalStrehovsky commented Jul 17, 2017

we're a couple months beyond .NET Native's public announcement turning 3 years old

Just to point out what may not be obvious: the .NET Native that was announced 3 years ago was .NET Native for Windows Store apps. This has shipped about a year after the announcement and is the shipping story for Windows Store apps in Visual Studio 2015/2017.

@MichalStrehovsky

This comment has been minimized.

Show comment
Hide comment
Member

MichalStrehovsky commented Nov 8, 2017

Fixed in #4870.

@perlun

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment