From 6.0 to 7.1 or 7.0 was indeed pretty awful, since 6.0 was far from
standards compliant.
especially regarding template classes. from 7.1 to 8.0 I have had far less
problems for code that is standards compliant.

migrating only converts the project files. not the source files.

The following macros can take care of that:
_CRT_SECURE_NO_DEPRECATE;_SECURE_ATL=0;_SECURE_SCL=0;_ATL_INSECURE_DEPRECATE(a);_ATL_DEBUG_INTERFACES
you may want to use one or more of these, depending on what type of project
you have.

I don't know MIDL all that well, but MIDL2020 is not a specific access
denied error code, according to MSDN2:
"The type library could not be generated. One possible cause of this error
is specifying a path to the IDL file that is longer than 126 characters.
Oleaut32.dll does not support path names longer than 126 characters."

maybe there is another reason for that error?

Quote:
Hello people,

We have a large application (about 5000 source files) consisting of multiple
executables, DLLs and COM components written in C++.
We develop and build it in Visual Studio 2003.

I'm in charge of evaluating whether we want to migrate it to VS2005 (the
previous migration from 6.0 to 7.1 was a pain).
So far, things do not look good.

I installed VS2005 on a VM, copied the sources over and tried to build the
solution.

First, it wanted to migrate all the projects.
OK, so far - so good.

Then, when I tried a "build solution" it crapped out with heaps of errors
and warnings.

The "deprecated" messages are a pain since adding the definitions to the
projects only works sometimes.

But what bothers me more are errors such as this one:

   midl\oleaut32.dll : error MIDL2020 : error generating type library :
   SaveAllChanges Failed : .\../lib/s_tplate.tlb (0x80070005)

Firing up process explorer, it looks like Visual Studio itself holds the
s_tplate.tlb file open so, obviously, trying to build it results in "access
denied" errors.

How do I solve this problem?
End Quote

I know that in MVC++ .net 2003 if I run a program in debug mode and it
crashes horribly when I end debug the program and try to compile I get a
similar error.  If I bring up task manager with ctrl-alt-del I can see that
my program is still running as a process.  I end the process, recompile and
all is well.

     I've noticed something similar.
     I downloaded a multiproject solution.  All projects source code
and *.vcproj's were in a common directory, all output binaries were
going to a common directory, and there were project dependencies.
I converted everthing up to VS2005.  I tried to compile.  There was a
project X which depended on project Y.  Both X and Y wanted to create
the same build log file L.  Compiling X would open L and lock it, then
since X depended on Y, compiling Y would attempt to open L on the
same directory and that is when the compilation failure happened.
     The way out of the problem was to put each project into its own
directory hanging off the solution directory, which is my normal
best practice.  Then the compilation went OK because although both
X and Y would open files named L, the two L's were now in different
directories.
    You might check to see if something like that is happening to you.

The problem still exists but I found some more information:

VS2005 definitely locks files because I got "access denied" errors when trying to _clean_ configurations.

Any suggestions?

Best wishes,
Alex.