Bug 11420 - Assembly.EntryPoint always returns the Entrypoint of the current executing assembly.
Summary: Assembly.EntryPoint always returns the Entrypoint of the current executing as...
Status: RESOLVED DUPLICATE of bug 11199
Alias: None
Product: Runtime
Classification: Mono
Component: Reflection ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-03-26 09:45 UTC by r-win
Modified: 2013-08-23 12:44 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test Solution (9.75 KB, application/x-zip-compressed)
2013-03-26 09:45 UTC, r-win
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED DUPLICATE of bug 11199

Description r-win 2013-03-26 09:45:38 UTC
Created attachment 3697 [details]
Test Solution

When using a packer like NetZ, it's possible that two assemblies with the same name are loaded.

The scenario is as follows. When you have one application with certain references, and you want to deploy a single executable, you can use NetZ. It will pack the assemblies as resources, and generates a new application. This application will mimic all AssemblyInfo of the original Application. When launched, it will extract the assemblies and load them (using Assembly.Load(byte[])). Then it will try to invoke the Main method of the loaded assembly. Because the wrapper application has the same assemblyname, and the same namespace (static class Program) and the same Entrypoint method, Mono will invoke the Main method of the wrapper application. Even though you've used the Assembly reference from Assembly.Load. 

The .NET framework handles this just fine.

Attached you'll find a solution which reproduces the problem. Expected output should be (.NET framework shows this):

Starting main executable
Starting wrapped executable

However, under Mono, the following output is shown (only the first 3 lines, they repeat until you get out of memory):

Starting main executable
Starting main executable
Starting main executable
....
Comment 1 r-win 2013-03-26 10:29:01 UTC
Apparently, this also fails when these are in different namespaces, and even when they're in different classes. Perhaps it has to do with the usage of the assembly.EntryPoint property.
Comment 2 r-win 2013-03-26 10:56:12 UTC
Finally, the problem seems to be this part:

            Assembly wrappedAssembly = Assembly.Load(assembly);

            MethodInfo mi = wrappedAssembly.EntryPoint;
            Console.WriteLine(mi.DeclaringType.FullName);
            Console.WriteLine(mi.Name);

The mi variable will always point to the entrypoint of the current assembly, and not of the wrappedAssembly.
Comment 3 Zoltan Varga 2013-03-27 10:56:11 UTC
Probably 'wrapperAssembly' is the current assembly, and not the one it tries to load.
Comment 4 r-win 2013-03-28 14:02:17 UTC
It's hard to detect that, since the assembly info is identical. This sample will work when you change one of the properties that define the full assemblyname. In my case, the workaround is to give a different assemblyname to the wrapping assembly, while keeping the wrapped assembly as the original.

It's still a bug though, but with a fairly good workaround afaic.
Comment 5 Rodrigo Kumpera 2013-08-23 12:44:32 UTC
Looks like the same issue of #11199

*** This bug has been marked as a duplicate of bug 11199 ***