[nem-en] Multiple project solutions
Kamil Skalski
kamil.skalski at gmail.com
Mon Jan 8 19:40:19 CET 2007
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.
--
Kamil Skalski
http://nazgul.omega.pl
More information about the devel-en
mailing list