[JEDI.NET discuss] Input required

[Marcel B. <mar...@xs...>]

All,

to those that have been following my adventures over in the borland.public.delphi.winforms.controls.writing NG (the thread 'A
class is not a class') you will have seen the trouble one runs into when dealing with a run time and a separate design time
assembly. For those who did not follow it, a short (yeah, right!) recap:

<recap>
I have a run time assembly with class X, which has the DesignerSerializer attribute to link the XCodeDomSerializer class in the
design time assembly. The attribute uses the AssemblyQualifiedName (since a run time assembly by convention can never reference
the design assembly directly) of the designer class to connect it. The design time assembly has a reference to the runtime
assembly (the Requires node).

Since the IDE won't be able to find anything that is not in the GAC or in the Assembly Search Paths list (the list you get through
Component|Installed .NET Components, tab 'Assembly Search Paths'), I added the 'jedidotnet/main/bin' folder to that list. That
works (my initial test just spit out a number of comments to show me the contents of the context stack), but as soon as I changed
it to actually write out what it was supposed to write out, I got an 'object reference set to nil' kind of message. After
commenting out everything and add a single line between tests, it all broke down once the value parameter of the Serialize method
(which holds an instance of X) was type cast to X.

Tests finally showed that although the value.GetType type info and the TypeOf(X) type info, seemed identical, there is one major
difference. The <type>.Assembly.Location holds the location from which the assembly is loaded, but for the value parameter it is
empty, while for the TypeOf(X) it was set to the location of the assembly dll.

My initial correction was to use reflection on the value parameter to get the info on the three properties I needed and used the
PropertyInfo structures to actually obtain the value. This works like a charm, but I didn't like the approach at all. After some t
hinking I got the brilliant thought to separate the run time and design time assemblies into two different folders, and only add
the design assembly to the list of search paths. Woohoo, success.
</recap>

Now, what bothers me about this whole change in setup is not so much the additional folder (I can live with that just fine), but
the fact that more problems might be lurking. What really weirds me out is that I have not find any evidence this problem occurs
with the MS provided assemblies (which are all in the same physical folder). Does anyone here know of something I may have
overlooked? The above seems to indicate the run time assembly of the component is recreated in memory, which I assume is done to
avoid the .dll from being locked in case you do a rebuild of the assembly. Is that a Delphi only thing, or does this happen in
VS.NET as well? Is it possible to specify somewhere that the assembly resolver should first look at it's internally recreated
assemblies, before trying to find one in the search path? The types in a recreated assembly do have the exact same
AssemblyQualifiedName values as the ones in the actual file, so it seems .NET is just discarding them as equal because the
Location value differs.

--
Marcel Bestebroer (Team JEDI) http://delphi-jedi.org
Project JEDI Help coordinator
JEDI.NET team coordinator