[nem-en] Multiple project solutions

[NoiseEHC]

What I would would suggest is:
(Note that in Hungary what I do is called "hitting the stinging-nettle 
with others' dick" but I hope that you will forget me.)

The current assembly is a project which references macro assembly with /m
- if the macro assembly is compiled then use macros from it normally 
(whatever features you implemented)
- if the macro assembly cannot be compiled on the fly then use the 
latest version
- if there is no latest version then disable everything in the current 
assembly (error highlight, colorization)

Anyway, you can do other thing from the macro assembly (code completion 
etc) in the same way if
it would be referenced with /r. Maybe in that case it could simply 
disable everything but it is up to you.

So the point is that the user should simply accept that they should have 
a working macro assembly and
simply accept the limitations until he fixes that.


Kamil Skalski wrote:
> 2007/1/8, vc <vc at rsdn.ru>:
>> > I would strongly suggest to use macros only from the last compiled
>> > version. You really should
>> > not waste time trying to use halfway implemented macros from 
>> source. It
>> > will not succeed...
>>
>> Hm... It's demands to reject combine library code with macro-code.
>
> Is it possible to track if the compiled version of macro library
> exists? If so we could switch between the "real" mode with executing
> referenced macros and the "fallback" to just show that macro exists,
> but not running it. In both modes we can still have normal classes
> shown  like for other libraries - they will just be ExternalType
> (implemeting TypeInfo) or TypeBuilder.
>
>> We must introduce rule - macro-assembly can contain only cacros and 
>> private
>> code.
>
> I'm a little bit afraid about the quite common scenario:
> - I have a macro library, which can generate some classes (e.g. O/R
> mapping for given data-base)
> - in my primary dll I use the macro to generate classes, which I use 
> extensively
>
> Now in the "fallback" mode, when macro is not run, what will happen
> with my references to generated stuff? I will get tons of errors. My
> opinion is that we should not have this fallback mode and always
> require macro library to be compiled before we start editing project,
> which  uses it.
> I know it might be quite disturbing for a user... but macro must be
> somehow compiled to be executed - may it be the actual compilation
> done by compiler or maybe some "hidden" temporary compilation by VS
> itself.
> Note that there is similar issue with VS designer - it must have the
> compiled version of your  Form to show it in designer. It does some
> magic to achieve it (which unfortunately fails VERY often for me), but
> the issue is essentially the same.
>
>> Also we should separate reference assembly and macro-reference.
>>
>
> This difference exists on the compiler level right now - you can use
> /r  with to reference a library and /m to just load macros from
> specified assembly. But it is sometimes useful to load macro library
> with /r, for example macro might generate uses of utility classes,
> which are defined in the same assembly.
>
>
>