G
Guest
Regarding my post "CSharpCodeProvider: referencing other generated "InMemory"
assembly" 4/27/2006 and the blog from Greg Young
http://geekswithblogs.net/gyoung/archive/2006/04/27/76533.aspx
I have now implemented a fine system with code semilar to Greg's example code.
I have a warning/comment/question:
When the generated main assembly is called for the first time (in my
application a static initialize function) another instance of the dependant
assemblies are loaded - and NOT the instances (System.Reflection.Assembly)
you have a reference to from results.CompiledAssembly !!! See trace @ bottom
of post.
That means that any initialization done in the sub-dlls before calling the
main assembly is kind of lost.
And: Files ARE created when named - even if cp.GenerateInMemory is set to
true! They are created in the application directory. That's where they're
loaded from when generated main assembly loads.
I haven't found a method yet to ensure the already loaded dlls are used.
I tried to instanciate an object from each assembly and keep the reference
to make sure that the assemblies does not get unloaded. No difference.
After the compilation the Assembly-reference property "ReflectionOnly" is
false as I expected.
Any help or hints appreciated.
FYI: I have solved the problem for now by letting all generated assemblies
initialize other used assemblies in their static Initialize function. I'm not
pleased with the solution but it works for now. This way I only initialize
yhe actually used instances.
A listing of the problematic scenario from my debug trace:
----------------------------------------------------------------------------
'MyApp.exe' (Managed): Loaded 'Lib1', No symbols loaded.
Initializing runtime sequence file Lib1
..
..
'MyApp.exe' (Managed): Loaded 'Lib2', No symbols loaded.
Initializing runtime sequence file Lib2
..
..
'MyApp.exe' (Managed): Loaded 'Main', No symbols loaded.
'MyApp.exe' (Managed): Loaded 'C:\Test\Lib1.DLL', Symbols loaded.
'MyApp.exe' (Managed): Loaded 'C:\Test\Lib2.DLL', Symbols loaded.
Initializing runtime sequence file Main
assembly" 4/27/2006 and the blog from Greg Young
http://geekswithblogs.net/gyoung/archive/2006/04/27/76533.aspx
I have now implemented a fine system with code semilar to Greg's example code.
I have a warning/comment/question:
When the generated main assembly is called for the first time (in my
application a static initialize function) another instance of the dependant
assemblies are loaded - and NOT the instances (System.Reflection.Assembly)
you have a reference to from results.CompiledAssembly !!! See trace @ bottom
of post.
That means that any initialization done in the sub-dlls before calling the
main assembly is kind of lost.
And: Files ARE created when named - even if cp.GenerateInMemory is set to
true! They are created in the application directory. That's where they're
loaded from when generated main assembly loads.
I haven't found a method yet to ensure the already loaded dlls are used.
I tried to instanciate an object from each assembly and keep the reference
to make sure that the assemblies does not get unloaded. No difference.
After the compilation the Assembly-reference property "ReflectionOnly" is
false as I expected.
Any help or hints appreciated.
FYI: I have solved the problem for now by letting all generated assemblies
initialize other used assemblies in their static Initialize function. I'm not
pleased with the solution but it works for now. This way I only initialize
yhe actually used instances.
A listing of the problematic scenario from my debug trace:
----------------------------------------------------------------------------
'MyApp.exe' (Managed): Loaded 'Lib1', No symbols loaded.
Initializing runtime sequence file Lib1
..
..
'MyApp.exe' (Managed): Loaded 'Lib2', No symbols loaded.
Initializing runtime sequence file Lib2
..
..
'MyApp.exe' (Managed): Loaded 'Main', No symbols loaded.
'MyApp.exe' (Managed): Loaded 'C:\Test\Lib1.DLL', Symbols loaded.
'MyApp.exe' (Managed): Loaded 'C:\Test\Lib2.DLL', Symbols loaded.
Initializing runtime sequence file Main