VS 15.3 came with new unexpected and not actionable warnings #1521
Comments
|
Hey @konste, long time no see, what are you up to these days, how are you doing? mail me at kevinr @ you know where. Kevin |
|
Are you seeing a similar warning from ResolveAssemblyReferences? We have similar code here that's in RAR and we tried to replicate the exception handling behavior. I would suspect that if this warns RAR would warn too. If there is a difference here it would be good to have repro steps and we can see what we need to do to fix it. I think the suggestions around a warning code and adding the actual file path are good and things we should do /cc @dsplaisted. |
|
Actually if you can add more detailed logs to output which referred assembly causes this warnings that will be better. The code existing in this file: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Extensions.Tasks/GetDependsOnNETStandard.cs There is only one log statement without detailed file information in the exception. Please make an improvement to the log. |
|
As I mentioned I think we should improve the log regardless. What I'm still trying to understand is if there is a different issue here as well where we have a discrepency with RAR in how we handle non-.net assemblies. @konste if it is possible for you to put a diag log up somewhere that would be helpful. |
|
@ericstj We definitely don't get anything resembling that warning from ResolveAssemblyReferences, so it must be different issue. I'd be glad to provide you with the repro, but to make it we first need to figure out what file causes it. |
|
@konste Hi master, got it. I was wondering whether it is security to post our build logs in public conversation. Since you have agreed I will repro and post it now. |
|
No need to share the whole log, if you can instrument and replace then that's awesome and more than I was expecting. Hopefully once we know what file is causing this we can identify what type of file it is the produce an isolated repro. |
|
Instrumentation have shown that GetFileDependsOnNETStandard chokes on assembly obfuscated with .NET Reactor, while ResolveAssemblyReferences does not have a problem with it and overall it loads and works fine. |
|
Sorry, will provide the logs tomorrow (it's late night in Singapore now)
…On 23 Aug 2017 23:44, "Konstantin Erman" ***@***.***> wrote:
Instrumentation have shown that GetFileDependsOnNETStandard chokes on
assembly obfuscated with .NET Reactor, while ResolveAssemblyReferences does
not have a problem with it and overall it loads and works fine.
I have asked my colleague @tishion <https://github.com/tishion> to
prepare and share minimized repro.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1521 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFmRcqFGitCLukTTCk9ZHrLReWJSvyayks5sbEjZgaJpZM4O8bOI>
.
|
|
The build log The demo project: |
|
@ericstj More information It doesn't log it with message beginning with warning/error or some other words so we will not get a warning items in the build log. I think it makes sense. But in the following task GetDependsOnNETStandard it logs the exception with the message starting with "warning" Here the word "warning" was caught by VS and we got one warning item. what makes us uncomfortable is there is no warning code so we could not ignore it by build configuration. I think the best way to fix this is stop logging this exception with LogWarning methods in this file This problem only happen when i switch the target framework of the exe to 4.6.1. there's no this warning message when i use target framework 4.6. |
|
For your convenience I can provide the demo project. |
Fix-#1521 Output the file path in warning message
|
I see that a PR was made and merged to address this issue. As such I am going to close this issue. If that's not the case, please, just comment and we can re-activate it. |
|
This was linked by at least one new devcomm issue, where no obfuscation is in use. EDIT: If this has been released, its still happening as of VS 15.5.4. The PR looks like it just adds some additional information to help find out which dll is the problem, not actually address the problem. Is this correct? For anyone else stuck with this error, here's how I was able to work around it. The exact error I get is... ... and since I dont have these bits yet, after some trial and error (remove a reference, rebuild, repeat), I found that it was the reference to The way its referenced dictates whether or not this particular error is thrown. Picking it from the "recent references" list creates this entry, which doesn't work for this specific project. <!--<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\..\..\..\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>-->However changing it to this works. <Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework" />I suspect the problem is likely due to the fact that there seem to be too many version 10 assemblies, or that the later of the two v10 assemblies is not in the PublicAssemblies folder. |
|
In our case, this appears to be related to projects created in older versions of Visual Studio and then opened in VS2017. These projects do not have the Adding this element to the top Oddly, many other projects that do not have this element still load and build correctly, so there is no obvious reason that these projects are special. Using VS2017, 15.6.2; projects were created in various patch versions of VS2013 and VS2015, and possibly even earlier versions. Anecdotally, this seems to be an issue in the tooling itself: applying an update patch to VS2017 would appear to work temporarily, but the issue would return some time later. |
|
@kmillerdevx3 given that this issue has been closed, I would suggest filling a new issue with new repro steps. Hopefully with a small repro repo on github. |
|
@livarcocc You closed it because you thought it was resolved. It is not. The pull request you referenced merely added more debugging information. |
|
@kmillerdevx3 could you maybe provide a new clean repro of the issue then? |
|
Creating a project file without the <Depends....> element seems like a clean and easy repro. |
|
But it doesn't effect all such projects. |
|
i had opened a devcomm issue with the feedback collection, etc. If you follow the link in the earlier post, and then go to the poorly handled linked issue, it should be available |
|
I have two projects that are nearly identical, but only one ran into this problem. I tracked it down to CommonServiceLocator (which the affected project wasn't using). Removing the reference removed the error. Literally a hundred other projects of similar vintage and definition have the same reference. None of them exhibit the issue. This only cropped up for me (or at least noticed) around 15.6.X. I then re-added the reference to the previous failing project, and the error returns: Every other project that references CommonServiceLocator without error has the same or similar reference. A diff of the reference shows only changes in the relative path. The warning persists whether or not packages.json asks for net45 or net462. |
|
At least in my case this may be the root cause: #1544 It apparently was fixed? #1548 I don't really see that though. In my case the hint path, when concatenated, is 265 characters: This has uncovered a problem with some unexpectedly nested directories, but still, not obvious when tracking this down. |
Thanks. It's resolved my issue. |
|
I am not sure if this related to this, but I received this error too after upgrading a DLL, which is now encrypted by .NET Reactor. |
After upgrade to VS 2017 15.3 and corresponding MSBuild our solution started to produce a lot of the following warnings:
Microsoft.NET.Build.Extensions.NETFramework.targets(48,5): warning : Resolved file has a bad image, no metadata, or is otherwise inaccessible. Index not found. (Exception from HRESULT: 0x80131124) [C:***.csproj]
@ericstj I believe it belongs to your GetDependsOnNETStandard task.
There are multiple problems with it. For one it does not have any MSB number and there is no way to look it up or to suppress it. Another problem - this warning is not actionable, as even with Diagnostics log level it does not tell which exactly binary caused the warning. And third - the warning is most probably bogus anyway and simply reacts on some unmanaged reference.
Please advise how we supposed to deal with it. It pollutes our otherwise clean build output.
The text was updated successfully, but these errors were encountered: