Bizarre and annoying compiler error message.

[rbazinet]

I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
my project I often times get this message:

Unexpected error creating debug information file 'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
process cannot access the file because it is being used by another process.
'

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

I have read posts that say to change to Release from Debug and back but that
is only temporary too and does not always work.

Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
compiler settings or code changes to be aware of?

I have also read to not have Enums inside my class, I did, and moved them to
just inside the namespace but that did not help either.

Finally, my project consists of a few User Controls which use this DLL. I
cannot determine when the error starts, I may do a build 10 times with no
problem but number 11 will be the problem, other times it takes 5 builds.

Thank you in advance,
Rob Bazinet

[Dave]

> If I exit Visual Studio and delete the obj directory under the DLL giving me

problems and they reload VS it works fine, but this is not a very good
solution. If you exit VS and restart without deleting the obj directory, does it work?

Since VS.NET is locking the Assembly, restarting should fix the issue without deleting the directory.

Try setting "CopyLocal" to true in the property grid on the assembly reference, if it is not already.

This will provide a copy of the referenced Assembly to VS.NET so that it can lock it for intellisense (which is what the cause of
your problem is, most likely).

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:B5**********************************@microsof t.com...I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
my project I often times get this message:

Unexpected error creating debug information file 'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
process cannot access the file because it is being used by another process.
'

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

I have read posts that say to change to Release from Debug and back but that
is only temporary too and does not always work.

Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
compiler settings or code changes to be aware of?

I have also read to not have Enums inside my class, I did, and moved them to
just inside the namespace but that did not help either.

Finally, my project consists of a few User Controls which use this DLL. I
cannot determine when the error starts, I may do a build 10 times with no
problem but number 11 will be the problem, other times it takes 5 builds.

Thank you in advance,
Rob Bazinet

[rbazinet]

Dave,

Thanks for the reply.

Yes, if I exit VS and go back in I do not have to delete the obj directory.
I am looking for a solution to my problem that can keep me in VS without
having to exit.

All of my DLL references for DLL are set to CopyLocal=true. Since I have a
bunch of other DLL's and this is not happening then it must be something
different about this DLL and this is the guidance I am looking for.

If I do a Google search on this problem I see it all over the place but no
real answers except exiting VS, which is not a solution.

-Rob
"Dave" wrote:

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

If you exit VS and restart without deleting the obj directory, does it work?

Since VS.NET is locking the Assembly, restarting should fix the issue without deleting the directory.

Try setting "CopyLocal" to true in the property grid on the assembly reference, if it is not already.

This will provide a copy of the referenced Assembly to VS.NET so that it can lock it for intellisense (which is what the cause of
your problem is, most likely).

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:B5**********************************@microsof t.com...

I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
my project I often times get this message:

Unexpected error creating debug information file 'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
process cannot access the file because it is being used by another process.
'

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

I have read posts that say to change to Release from Debug and back but that
is only temporary too and does not always work.

Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
compiler settings or code changes to be aware of?

I have also read to not have Enums inside my class, I did, and moved them to
just inside the namespace but that did not help either.

Finally, my project consists of a few User Controls which use this DLL. I
cannot determine when the error starts, I may do a build 10 times with no
problem but number 11 will be the problem, other times it takes 5 builds.

Thank you in advance,
Rob Bazinet

[Dave]

This is where I found my information, but I couldn't find anything about your particular "debug file" issue other than in the
compiler documentation and that didn't add anything useful:

http://support.microsoft.com/default...b;en-us;313512

Maybe VS.net is locking your debug file when it loads your UserControls into the toolbox, but other than that I see no reason for
VS.net to even need the .pdb file.

Sorry I couldn't help more.

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:8D**********************************@microsof t.com...

Dave,

Thanks for the reply.

Yes, if I exit VS and go back in I do not have to delete the obj directory.
I am looking for a solution to my problem that can keep me in VS without
having to exit.

All of my DLL references for DLL are set to CopyLocal=true. Since I have a
bunch of other DLL's and this is not happening then it must be something
different about this DLL and this is the guidance I am looking for.

If I do a Google search on this problem I see it all over the place but no
real answers except exiting VS, which is not a solution.

-Rob
"Dave" wrote:

> If I exit Visual Studio and delete the obj directory under the DLL giving me
> problems and they reload VS it works fine, but this is not a very good
> solution.

If you exit VS and restart without deleting the obj directory, does it work?

Since VS.NET is locking the Assembly, restarting should fix the issue without deleting the directory.

Try setting "CopyLocal" to true in the property grid on the assembly reference, if it is not already.

This will provide a copy of the referenced Assembly to VS.NET so that it can lock it for intellisense (which is what the cause of
your problem is, most likely).

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:B5**********************************@microsof t.com...

>I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
> my project I often times get this message:
>
> Unexpected error creating debug information file 'C:\DevProjects\Allstar
> Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
> 'C:\DevProjects\Allstar
> Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
> process cannot access the file because it is being used by another process.
> '
>
> If I exit Visual Studio and delete the obj directory under the DLL giving me
> problems and they reload VS it works fine, but this is not a very good
> solution.
>
> I have read posts that say to change to Release from Debug and back but that
> is only temporary too and does not always work.
>
> Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
> compiler settings or code changes to be aware of?
>
> I have also read to not have Enums inside my class, I did, and moved them to
> just inside the namespace but that did not help either.
>
> Finally, my project consists of a few User Controls which use this DLL. I
> cannot determine when the error starts, I may do a build 10 times with no
> problem but number 11 will be the problem, other times it takes 5 builds.
>
> Thank you in advance,
> Rob Bazinet
>

[Dan Kelley]

I just read about the same issue in Frans Boumas blog:

http://weblogs.asp.net/fbouma/archive/2005/07/13.aspx

There is a link in the blog to an MSDN KB article. Apparently there is a
fix, but you have to request it.

HTH
Dan

"rbazinet" wrote:

I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
my project I often times get this message:

Unexpected error creating debug information file 'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
process cannot access the file because it is being used by another process.
'

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

I have read posts that say to change to Release from Debug and back but that
is only temporary too and does not always work.

Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
compiler settings or code changes to be aware of?

I have also read to not have Enums inside my class, I did, and moved them to
just inside the namespace but that did not help either.

Finally, my project consists of a few User Controls which use this DLL. I
cannot determine when the error starts, I may do a build 10 times with no
problem but number 11 will be the problem, other times it takes 5 builds.

Thank you in advance,
Rob Bazinet

[rbazinet]

Dan,

Thank you for the post. It's interesting to see it is such a widespread
issue with a solution that is not publicly available. I called Microsoft and
requested the fix, I have installed it and all seems good so far.

FWIW, the tech I spoke with on the C# Support Team said a service pack for
VS.NET 2003 is expected in August/September timeframe.

-Rob
"Dan Kelley" wrote:

I just read about the same issue in Frans Boumas blog:

http://weblogs.asp.net/fbouma/archive/2005/07/13.aspx

There is a link in the blog to an MSDN KB article. Apparently there is a
fix, but you have to request it.

HTH
Dan

"rbazinet" wrote:

I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
my project I often times get this message:

Unexpected error creating debug information file 'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
'C:\DevProjects\Allstar
Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
process cannot access the file because it is being used by another process.
'

If I exit Visual Studio and delete the obj directory under the DLL giving me
problems and they reload VS it works fine, but this is not a very good
solution.

I have read posts that say to change to Release from Debug and back but that
is only temporary too and does not always work.

Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
compiler settings or code changes to be aware of?

I have also read to not have Enums inside my class, I did, and moved them to
just inside the namespace but that did not help either.

Finally, my project consists of a few User Controls which use this DLL. I
cannot determine when the error starts, I may do a build 10 times with no
problem but number 11 will be the problem, other times it takes 5 builds.

Thank you in advance,
Rob Bazinet

[rbazinet]

Dave,

Your help is much appreciated. If you look at Dan Kelley's post on this
thread you can see a link to somone else who has the problem and the fix. It
seems MS has a hotfix for this problem that is available by request.

Thanks,
Rob
"Dave" wrote:

This is where I found my information, but I couldn't find anything about your particular "debug file" issue other than in the
compiler documentation and that didn't add anything useful:

http://support.microsoft.com/default...b;en-us;313512

Maybe VS.net is locking your debug file when it loads your UserControls into the toolbox, but other than that I see no reason for
VS.net to even need the .pdb file.

Sorry I couldn't help more.

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:8D**********************************@microsof t.com...

Dave,

Thanks for the reply.

Yes, if I exit VS and go back in I do not have to delete the obj directory.
I am looking for a solution to my problem that can keep me in VS without
having to exit.

All of my DLL references for DLL are set to CopyLocal=true. Since I have a
bunch of other DLL's and this is not happening then it must be something
different about this DLL and this is the guidance I am looking for.

If I do a Google search on this problem I see it all over the place but no
real answers except exiting VS, which is not a solution.

-Rob
"Dave" wrote:

> If I exit Visual Studio and delete the obj directory under the DLL giving me
> problems and they reload VS it works fine, but this is not a very good
> solution.
If you exit VS and restart without deleting the obj directory, does it work?

Since VS.NET is locking the Assembly, restarting should fix the issue without deleting the directory.

Try setting "CopyLocal" to true in the property grid on the assembly reference, if it is not already.

This will provide a copy of the referenced Assembly to VS.NET so that it can lock it for intellisense (which is what the cause of
your problem is, most likely).

--
Dave Sexton
dave@www..jwaonline..com
-----------------------------------------------------------------------
"rbazinet" <rb******@discussions.microsoft.com> wrote in message news:B5**********************************@microsof t.com...
>I have a VS 2003 C# project, web app with a bunch of DLL's. When I compile
> my project I often times get this message:
>
> Unexpected error creating debug information file 'C:\DevProjects\Allstar
> Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.PDB' --
> 'C:\DevProjects\Allstar
> Admin\Allstar.Common.DataAccess\obj\Debug\Allstar. Common.DataAccess.pdb: The
> process cannot access the file because it is being used by another process.
> '
>
> If I exit Visual Studio and delete the obj directory under the DLL giving me
> problems and they reload VS it works fine, but this is not a very good
> solution.
>
> I have read posts that say to change to Release from Debug and back but that
> is only temporary too and does not always work.
>
> Obviously DEVENV.EXE has ahold of my DLL. Any ideas how to fix this with
> compiler settings or code changes to be aware of?
>
> I have also read to not have Enums inside my class, I did, and moved them to
> just inside the namespace but that did not help either.
>
> Finally, my project consists of a few User Controls which use this DLL. I
> cannot determine when the error starts, I may do a build 10 times with no
> problem but number 11 will be the problem, other times it takes 5 builds.
>
> Thank you in advance,
> Rob Bazinet
>