[nem-en] Multiple project solutions

[Kamil Skalski]

I attach the skeleton implementation, which should do the basic job.
You need to test and extend it by yourself, as you know exactly when
and how to use it now.
I'm not sure how critical will mixing of TypeBuilders created by
different Managers will be, but I guess it should work in most
scenarios - especially that they are just references.

As for the assembly locking, I guess you can better implement it
yourself - just replace the offending calls to Assembly.Load by global
static cache used across all projects.

2007/1/6, vc <vc at rsdn.ru>:
> > Does metadata info in VS have some common data-structure? For example
> > what if you wanted to mix two languages and reference Nemerle from C#
> > or C# from Nemerle?
>
> C#/VB/MC++ project will be supported only over assembly references. MS not
> open in API.

Ok, I think it will be always easier to deal with Nemerle - Nemerle
case by our own API - if VS guys create their own metadata API, then
we can use it to communicate with other languages.

>
> > If we are talking only about Nemerle - Nemerle cooperation,
>
> Exactly.
>
> > it seems
> > possible to implement in compiler API - we need to populate one
> > NamespaceTree with nodes from referenced projects' TypeBuilders  (by
> > GetTypeBuilders method in their NamespaceTree I guess).
>
> And we need remove external TypeBuilders if it project has been changed.

Just like you said - if used change project A and goes to the
dependent project B, then you need to clean whole tree in B, just like
one added/removed library reference.

Also, I think that sometimes it would be good to use the compiled
assembly as reference.

>
> > The little problem here is that you would need to clean builders
> > during recompilation not only in current project, but also in
> > referencing ones.
>
> We use on demand compilation (NamespaceTree building). If project has been
> changed we reset reference on it NamespaceTree. When user touch it project
> we rebuild corresponding NamespaceTree. In it's time we can reload types
> from another project (If we can understand that it has been changed).
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


-- 
Kamil Skalski
http://nazgul.omega.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addexternal.diff
Type: text/x-patch
Size: 1319 bytes
Desc: not available
Url : /mailman/pipermail/devel-en/attachments/20070106/9a40f94d/addexternal.bin