Unexpected error writing metadata. WTF?

[=?ISO-8859-15?Q?R=FCdiger_Klaehn?=]

I am getting this very annoying error CS0013 whenever I try to build a
complex library. I had the problem a few months ago, and followed the
advice from the knowledge base and reinstalled visual studio.

Now I have a fresh install of WinXP pro, a fresh install of VS.NET 2003,
and yet the same problem occurs again!

The problem persists even when I do not use visual studio. I am
currently consolidating my build process using nant, and the same
problem occurs.

I have searched the net and found many people having the same problem,
but not a single solution. Somebody please help me. This is getting
quite urgent.

best regards

Rüdiger

 

[Nicholas Paldino [.NET/C# MVP]]

Rüdiger,

I would compare what VS.NET is using to compile versus using NAnt.
Basically, check the command line that VS.NET is using (which is in the
output window when you build), and then check out the command line that NAnt
is using for the same project.

You might be able to see some differences there which might account for
the CS0013 error.

Also, if you have the luxury of waiting, or working with beta products,
you might want to try out VS.NET 2005, and the MSBUILD system. The IDE and
the command line builder use the same engine, and you won't have to worry
about divergence between the IDE and command line tools.

Hope this helps.

 

[=?ISO-8859-15?Q?R=FCdiger_Klaehn?=]

Rüdiger,

I would compare what VS.NET is using to compile versus using NAnt.
Basically, check the command line that VS.NET is using (which is in the
output window when you build), and then check out the command line that NAnt
is using for the same project.

VS.Net has the same problem, so I don't see how that should help. By the
way, I have the exact same problem when running csc from the command line.

[snip]

Also, if you have the luxury of waiting, or working with beta products,
you might want to try out VS.NET 2005, and the MSBUILD system. The IDE and
the command line builder use the same engine, and you won't have to worry
about divergence between the IDE and command line tools.

I don't have the luxury of waiting, and I am not going to change the
build system again in the vague hope that it might work.

The target file does not even exist, and there is no process owns a
handle to the target file (I checked with process explorer).

I am really running out of things to try...

Hope this helps.

I'm afraid not. But thanks anyway.

 

[Nicholas Paldino [.NET/C# MVP]]

Rüdiger,

Does this address your problem (watch for line wrap)?

http://support.microsoft.com/default.aspx?scid=kb;EN-US;843552

You mentioned the complexity of your library, and I'm wondering if this
might be the cause.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Rüdiger,

I would compare what VS.NET is using to compile versus using NAnt.
Basically, check the command line that VS.NET is using (which is in the
output window when you build), and then check out the command line that
NAnt is using for the same project.

VS.Net has the same problem, so I don't see how that should help. By the
way, I have the exact same problem when running csc from the command line.

[snip]

Also, if you have the luxury of waiting, or working with beta
products, you might want to try out VS.NET 2005, and the MSBUILD system.
The IDE and the command line builder use the same engine, and you won't
have to worry about divergence between the IDE and command line tools.

I don't have the luxury of waiting, and I am not going to change the build
system again in the vague hope that it might work.

The target file does not even exist, and there is no process owns a handle
to the target file (I checked with process explorer).

I am really running out of things to try...

Hope this helps.

I'm afraid not. But thanks anyway.

 

[=?ISO-8859-15?Q?R=FCdiger_Klaehn?=]

Rüdiger,

Does this address your problem (watch for line wrap)?

http://support.microsoft.com/default.aspx?scid=kb;EN-US;843552

You mentioned the complexity of your library, and I'm wondering if this
might be the cause.

This might be it. The library is not really large, but I use inner
classes and a quite large inheritance hierarchy.

So how do I get this hotfix? I did not see a download link in the page.

By the way: this is not only a problem with VS.NET 2003, but also with
2002 and even the straight csc.exe from the .net framework. Given the
fact that there are a lot of people having this problem there should
really be a fix.

I will try to reorganize the class hierarchy to avoid inner classes. But
you should not have to adapt your inheritance hierarchy to compiler bugs...

Many thanks for the quick response.

 

[Nicholas Paldino [.NET/C# MVP]]

Rüdiger,

Follow this link for the contact number page (watch for line wrap):

http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS

It was listed under the "Resolution" section of the link in the previous
page.

Also, I am curious, when I entered CS0013 into google, the support page
I referenced previously was the first link. I'm curious how you missed it
=)

 

[=?ISO-8859-15?Q?R=FCdiger_Klaehn?=]

Rüdiger,

Follow this link for the contact number page (watch for line wrap):

http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS

It was listed under the "Resolution" section of the link in the previous
page.

Also, I am curious, when I entered CS0013 into google, the support page
I referenced previously was the first link. I'm curious how you missed it
=)

It was not there the last time I looked for this problem (in november
2004).

I just called the number and there is nobody there except an answering
machine. So I guess I will have to wait until tommorrow... :-(

Why can't they just provide a download link for the fix? This is a major
compiler bug, so you should fix it as soon as possible.

 

[Nicholas Paldino [.NET/C# MVP]]

Rüdiger,

You realize that I don't work for Microsoft, correct? So when you say
"you should fix it as soon as possible", you should understand that I am not
inclined to reverse engineer the compiler and fix your particular problem.

It's a national holiday in America today, so that might account for why
that particular branch of customer service (for hotfixes) is not responding.

I agree that it should be an easier download. However, due to the
nature of hotfixes, I think that they want you to go through the process of
speaking with someone so you understand what the liability is. Hotfixes are
not guaranteed in any way, and they are not put through the same testing
that other products are put through, hence the hesitation to release in a
public distribution. I would expect this to be officially addressed in the
next service pack, or in .NET 2.0.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Rüdiger,

Follow this link for the contact number page (watch for line wrap):

http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS

It was listed under the "Resolution" section of the link in the
previous page.

Also, I am curious, when I entered CS0013 into google, the support
page I referenced previously was the first link. I'm curious how you
missed it =)

It was not there the last time I looked for this problem (in november
2004).

I just called the number and there is nobody there except an answering
machine. So I guess I will have to wait until tommorrow... :-(

Why can't they just provide a download link for the fix? This is a major
compiler bug, so you should fix it as soon as possible.

 

[=?ISO-8859-15?Q?R=FCdiger_Klaehn?=]

Rüdiger,

You realize that I don't work for Microsoft, correct? So when you say
"you should fix it as soon as possible", you should understand that I am not
inclined to reverse engineer the compiler and fix your particular problem.

I guess that I read the [..MVP] as [..MSFT]. I apologise for being rude
to you. Its not your fault after all.

It's a national holiday in America today, so that might account for why
that particular branch of customer service (for hotfixes) is not responding.

I agree that it should be an easier download. However, due to the
nature of hotfixes, I think that they want you to go through the process of
speaking with someone so you understand what the liability is. Hotfixes are
not guaranteed in any way, and they are not put through the same testing
that other products are put through, hence the hesitation to release in a
public distribution. I would expect this to be officially addressed in the
next service pack, or in .NET 2.0.

I sure hope so. This has cost me quite a lot of time that could have
been spent much more productively.

best regards,

Rüdiger