Metadata importing puzzle

  • Thread starter Thread starter Gerhard Menzl
  • Start date Start date
G

Gerhard Menzl

When using another assembly, I prefer adding it to the References
section of the project that uses it (thus adding the appropriate /FU
option to the compiler command line) over an explicit #using directive
in the source code. So far, this has worked without any problems.

Recently, however, I tried to reference an assembly for which this just
doesn't work. I have added it to References, the emitted command line
contains the /FU option with the correct path, and yet the compiler does
not recognize any of its types. Once I add a #using directive of
identical content to the source file to be compiled - normally a
redundant step -, the problem goes away.

Has anyone ever experienced anything like this and can provide an
explanantion or at least a clue? Does it make a difference whether the
assembly to be used was written in C# or C++?
 
--------------------
From: Gerhard Menzl <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vc
Subject: Metadata importing puzzle
Date: Fri, 04 Jun 2004 10:56:12 +0200

When using another assembly, I prefer adding it to the References
section of the project that uses it (thus adding the appropriate /FU
option to the compiler command line) over an explicit #using directive
in the source code. So far, this has worked without any problems.

Recently, however, I tried to reference an assembly for which this just
doesn't work. I have added it to References, the emitted command line
contains the /FU option with the correct path, and yet the compiler does
not recognize any of its types. Once I add a #using directive of
identical content to the source file to be compiled - normally a
redundant step -, the problem goes away.

Has anyone ever experienced anything like this and can provide an
explanantion or at least a clue? Does it make a difference whether the
assembly to be used was written in C# or C++?
Click to expand...

Check the buildlog.htm and make sure the /FU was actually passed to the
compiler. Also, sometimes the order of assembly import makes a difference
- #using is effectively reordering the references, which may make it work.
 
Arjun said:
Check the buildlog.htm and make sure the /FU was actually passed to the
compiler. Also, sometimes the order of assembly import makes a difference
- #using is effectively reordering the references, which may make it work.
Click to expand...

I did check buildlog.htm; actually, that's what I was referring to when
I wrote "the emitted command line". Why should the order of references
be of any importance? Also I'm not aware of any way of influencing it.

Strangest of all, after several builds with the #using directive, I
removed it, and now everything works as expected. What is going on here?
 
--------------------
From: Gerhard Menzl <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vc
Subject: Re: Metadata importing puzzle
Date: Mon, 07 Jun 2004 09:19:00 +0200 work.

I did check buildlog.htm; actually, that's what I was referring to when
I wrote "the emitted command line". Why should the order of references
be of any importance? Also I'm not aware of any way of influencing it.

Strangest of all, after several builds with the #using directive, I
removed it, and now everything works as expected. What is going on here?
Click to expand...

Since the compiler does some type resolution when importing an assembly,
order of reference can sometimes affect the outcome. This is rare, and
results in compiler errors ("xyz not defined").

If it started working after repeated builds, I can only suspect that types
were missing, and somehow the assemblies were updated to include those
types. Is this possible?
 
Arjun said:
If it started working after repeated builds, I can only suspect that
types were missing, and somehow the assemblies were updated to include
those types. Is this possible?
Click to expand...

I don't think so. But frankly, my schedule is way too tight to invest
much time in exploring this peculiarity. Thank you for your assistance.
 
Back
Top