-
Notifications
You must be signed in to change notification settings - Fork 217
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
Error merging VB app in 2.0.27 #347
Comments
can you add a /lib:dir option where dir is the directory containing Microsoft.VisualBasic.Core.dll? |
I can give it a go. I just have to figure out which of the 78 copies of Microsoft.VisualBasic.Core.DLL on my C: drive is the right one... |
I went with this one: Which got rid of the error during repacking. I'll have to test the resulting assembly later - I need to copy it to a test platform to confirm that it works. But while going through this exercise, I clicked that I'm still using VS 2017 for this particular library which is a .NET Framework 4.8 assembly, but Microsoft.VisualBasic.Core.DLL is a .NET 8.0 assembly. So I'm not sure why my library would be interested in it, or why ILRepack would want to look for it. Looking at the merged DLL using ILSpy, there is no reference to Microsoft.VisualBasic.Core.DLL. |
Cecil needs that dll to resolve some type references (understand signatures, metadata etc) of the input assemblies, even if the actual dll is not used. |
I’m guessing 2.0.18 was accidentally picking it up from some random location like the GAC or something. We did change the resolve algorithm to rely on the /lib: arguments to make it explicit which ones you need exactly, because people have been picking up wrong dlls from wrong locations accidentally. |
I still don't understand why it needs the location of a library that none of my assemblies are using, and that is for a different generation of framework. I've changed it to /lib:"%ProgramFiles(x86)%\dotnet\shared\Microsoft.NETCore.App\6.0.26", which is at least not as hard-coded, and in a "well-known" folder. |
You can install |
And if I do and .Basic.:
|
Because this is a fairly common "issue" for which we cannot do anything on development side. My suggestion is to catch the |
If you want to figure out why MS.VB.Core is needed, you need to debug, break in the debugger when it happens and examine the callstack. It will tell you what Cecil was looking at that required that dll. |
So its failing when trying to resolve Microsoft.VisualBasic.MyGroupCollectionAttribute, which in .NET 'core' lives in Microsoft.VisualBasic.Core, but in .NET 'Framework' lives in Microsoft.VisualBasic. Putting a break point in ReferenceFixator.FixReferences, I can see that the scope at this point is "{Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a}" It is still correct in Cecil.MetadataResolver Then, in TryResolve, it gets broken, after this, the version number has changed to 0.0.0.0:
The heuristic is not valid for Microsoft.VisualBasic, since the version number for the .NET Framework version of Microsoft.VisualBasic.dll is 10.0.0.0, and the .NET 8.0 version of Microsoft.VisualBasic.Core 8 is 13.0.x.y... If I skip that logic and go straight to |
Thanks for investigating! It does seem to be a problem, and a regression too, and my fault on top of it. I’ll take a look. |
I'm trying to reproduce this and I can't find a good repro. Any chance you would be able to create a minimal project that exhibits this problem? I'm guessing it should be relatively simple now knowing that a VB attribute is involved. Once I have a repro (without your added /lib argument) I'll be able to fix the heuristic in the resolver as well as emit a better error message for this situation. |
I had the same problem, so I did the same experiment as you and the problem happened to me as well @pricerc |
@Dark-Shadow-EGY You're saying that the problem happened to you. It didn't happen to me. I'd love to be able to reproduce the problem so I can fix it. If I can fix it, there's no need to ignore. Could you please describe your set up and repro steps exactly? What did you do? Where is Newtonsoft.Json.dll? Where is MS.VB.Core.dll? what is the arguments passed to ILRepack.exe? what is the current directory? Thanks. |
2024-05-28.09-01-28.mp4 |
Thanks all! @pricerc your insight was very helpful, and @Dark-Shadow-EGY with your video I was able to reproduce and fix. |
I'm using 2.0.18 ok, but nuget advised me that there was an update, so I decided to try it.
I run the repack in a post-build CMD file, with this snippet:
SET ILMERGE_VERSION=2.0.27
SET ILMERGE_PATH=%USERPROFILE%.nuget\packages\ilrepack%ILMERGE_VERSION%\tools\
Without doing anything else besides changing the minor version from 18 to 27, I get this error:
Failed to resolve assembly: 'Microsoft.VisualBasic.Core, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
The text was updated successfully, but these errors were encountered: