Skip to content
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
Open

MSB3246 should say *which* file #3650

rainersigwald opened this issue Aug 24, 2018 · 2 comments
Labels
Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. triaged

Comments

@rainersigwald
Copy link
Member

https://github.com/Microsoft/msbuild/blob/a8fba1ebd7b10ea68fcbdb8144a31496f8c37ce7/src/Tasks/Resources/Strings.resx#L1423-L1424

logged from

https://github.com/Microsoft/msbuild/blob/a8fba1ebd7b10ea68fcbdb8144a31496f8c37ce7/src/Tasks/AssemblyDependency/ResolveAssemblyReference.cs#L1523-L1528

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 rainersigwald added the Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. label Aug 24, 2018
@rainersigwald
Copy link
Member Author

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
Copy link
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.

@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Debuggability Issues impacting the diagnosability of builds, including logging and clearer error messages. triaged
Projects
None yet
Development

No branches or pull requests

3 participants