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

MSB3246 should say *which* file #3650

Open
rainersigwald opened this Issue Aug 24, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@rainersigwald
Contributor

rainersigwald commented Aug 24, 2018

<data name="ResolveAssemblyReference.FailedWithException">
<value>MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. {0}</value>

logged from

else if (itemError is BadImageReferenceException)
{
message = Log.FormatResourceString("ResolveAssemblyReference.FailedWithException", itemError.Message);
helpKeyword = "MSBuild.ResolveAssemblyReference.FailedWithException";
dependencyProblem = false;
}

Doesn't name a file, so you have to dig through more information to do anything about it.

Looks like everything in that block should list the reference in its error.

@rainersigwald

This comment has been minimized.

Show comment
Hide comment
@rainersigwald

rainersigwald Aug 31, 2018

Contributor

Talked with @shanselman who saw this on a machine where he'd also found several zero-byte files, which led to a nice repro:

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="deliberately.zero.bytes.dll" />
  </ItemGroup>

  <Target Name="WriteZeroByteFile" BeforeTargets="ResolveAssemblyReferences">
    <Touch Files="deliberately.zero.bytes.dll" AlwaysCreate="true" />
  </Target>

</Project>

Which leads to

$ dotnet build /flp:v=diag
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 57.05 ms for S:\work\zero-byte-ref\zero-byte-ref.csproj.
C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
  zero-byte-ref -> S:\work\zero-byte-ref\bin\Debug\netstandard2.0\zero-byte-ref.dll

Build succeeded.

C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.44

And in the diag log

...
                     Primary reference "deliberately.zero.bytes.dll". (TaskId:41)
13:43:49.856   1:7>C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
                         Resolved file path is "S:\work\zero-byte-ref\deliberately.zero.bytes.dll". (TaskId:41)
                         Reference found at search path location "{RawFileName}". (TaskId:41)
                             For SearchPath "{CandidateAssemblyFiles}". (TaskId:41)
                             Considered "deliberately.zero.bytes.dll",
                     			but its name "deliberately.zero.bytes"
                     			didn't match the expected name "deliberately.zero.bytes.dll". (TaskId:41)
...

So there's enough information to debug if you happened to up your logging level.

Contributor

rainersigwald commented Aug 31, 2018

Talked with @shanselman who saw this on a machine where he'd also found several zero-byte files, which led to a nice repro:

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <Reference Include="deliberately.zero.bytes.dll" />
  </ItemGroup>

  <Target Name="WriteZeroByteFile" BeforeTargets="ResolveAssemblyReferences">
    <Touch Files="deliberately.zero.bytes.dll" AlwaysCreate="true" />
  </Target>

</Project>

Which leads to

$ dotnet build /flp:v=diag
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 57.05 ms for S:\work\zero-byte-ref\zero-byte-ref.csproj.
C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
  zero-byte-ref -> S:\work\zero-byte-ref\bin\Debug\netstandard2.0\zero-byte-ref.dll

Build succeeded.

C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.44

And in the diag log

...
                     Primary reference "deliberately.zero.bytes.dll". (TaskId:41)
13:43:49.856   1:7>C:\Program Files\dotnet\sdk\2.1.400\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small. [S:\work\zero-byte-ref\zero-byte-ref.csproj]
                         Resolved file path is "S:\work\zero-byte-ref\deliberately.zero.bytes.dll". (TaskId:41)
                         Reference found at search path location "{RawFileName}". (TaskId:41)
                             For SearchPath "{CandidateAssemblyFiles}". (TaskId:41)
                             Considered "deliberately.zero.bytes.dll",
                     			but its name "deliberately.zero.bytes"
                     			didn't match the expected name "deliberately.zero.bytes.dll". (TaskId:41)
...

So there's enough information to debug if you happened to up your logging level.

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Sep 2, 2018

Contributor

fyi / other context - since @shanselman also found my SO answer while researching this live on youtube (https://stackoverflow.com/questions/48122173/warning-when-using-nuget-package-that-contains-native-dll)
This also happens when native DLLs are shipped in NuGet packages since AFAIK Core MSBuild uses different APIs (?) to inspect DLLs and thus complains on native DLLs that are placed inside NuGet lib/ folders instead of runtimes/ folders.
NuGet packages did this before netstandard/netcoreapp to ship native DLLs (e.g. sql drivers, things like zeromq libs etc.). When NuGet introduced the asset target fallback to net* assemblies, this started happening a lot more.
Would be good to know which package is responsible from the error message.

Contributor

dasMulli commented Sep 2, 2018

fyi / other context - since @shanselman also found my SO answer while researching this live on youtube (https://stackoverflow.com/questions/48122173/warning-when-using-nuget-package-that-contains-native-dll)
This also happens when native DLLs are shipped in NuGet packages since AFAIK Core MSBuild uses different APIs (?) to inspect DLLs and thus complains on native DLLs that are placed inside NuGet lib/ folders instead of runtimes/ folders.
NuGet packages did this before netstandard/netcoreapp to ship native DLLs (e.g. sql drivers, things like zeromq libs etc.). When NuGet introduced the asset target fallback to net* assemblies, this started happening a lot more.
Would be good to know which package is responsible from the error message.

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