Can we use dlls build with VS2005 with old apps?

[yevvi]

Hi,

We have a product with bunch of dlls which are now built with Visual
Studio 2003. We want to switch the build to use VS2005. I have read
that in VS2005 runtime libraries come as side-by-side assemblies and
that application has to have a manifest binding it to those assemblies.

My question is, can previously built apps use my new dlls build with
vs2005? It would be really important to make it work, because
otherwise we would have to ask all our customers to rebuild their apps
with vs2005. For now, when i try to build a sample application with
vs2003 and link it with dlls build with vs2005, the build is successful
but at runtime i get an error "could not find msvcr80.dll".

Also when i try to run odbc datasource manager which loads one of our
dlls, i get "system error 126", which is i guess the same as previous
one.

So, is there any way to make existing executables work with vs2005 dlls
without having to rebuild the executables? Using "mt" tool to put a
manifest in all our customers apps would not be a very good option.

Thanks a lot,
Yev

[yevvi]

Hi,
I also tried to run a java program, which loads our driver dll (now
build with vs2005)
and i m getting the same error. How would java app recognize vs2005
dlls? Do we need to use those manifests with java programs?

Thanks
Yev

ye***@yahoo.com wrote:

Hi,

We have a product with bunch of dlls which are now built with Visual
Studio 2003. We want to switch the build to use VS2005. I have read
that in VS2005 runtime libraries come as side-by-side assemblies and
that application has to have a manifest binding it to those assemblies.

My question is, can previously built apps use my new dlls build with
vs2005? It would be really important to make it work, because
otherwise we would have to ask all our customers to rebuild their apps
with vs2005. For now, when i try to build a sample application with
vs2003 and link it with dlls build with vs2005, the build is successful
but at runtime i get an error "could not find msvcr80.dll".

Also when i try to run odbc datasource manager which loads one of our
dlls, i get "system error 126", which is i guess the same as previous
one.

So, is there any way to make existing executables work with vs2005 dlls
without having to rebuild the executables? Using "mt" tool to put a
manifest in all our customers apps would not be a very good option.

Thanks a lot,
Yev

[Igor Tandetnik]

ye***@yahoo.com wrote:

My question is, can previously built apps use my new dlls build with
vs2005?
What kind of interface do your DLLs expose? If it's plain C API, or
COM-based interface, chances are high they would work. If you are
exporting C++ classes from DLL, your chances are slim to none.
It would be really important to make it work, because
otherwise we would have to ask all our customers to rebuild their apps
with vs2005. For now, when i try to build a sample application with
vs2003 and link it with dlls build with vs2005, the build is
successful but at runtime i get an error "could not find msvcr80.dll".

The easiest way around that is probably to link your DLLs against static
CRT: Project | Properties | C/C++ | Code Generation | Runtime Library =
Multithreaded (or Multithreaded Debug, when doing debug build).
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[yevvi]

Hi, thanks for the reply.

Some dlls export C API, and others export C++. But i would think if
there was a problem with C++ name decoration, i would get a different
kind of error, like "symbol not found".

I guess linking dlls with runtime statically would probably solve the
problem, but it would also make the footprint much bigger since all
runtime library code would have to be contained in each dll.

Any other way to do it?
Also, seems like java apps cannot use vs2005 dlls?

Thanks a lot
Yev

Igor Tandetnik wrote:

ye***@yahoo.com wrote:

My question is, can previously built apps use my new dlls build with
vs2005?

What kind of interface do your DLLs expose? If it's plain C API, or
COM-based interface, chances are high they would work. If you are
exporting C++ classes from DLL, your chances are slim to none.

It would be really important to make it work, because
otherwise we would have to ask all our customers to rebuild their apps
with vs2005. For now, when i try to build a sample application with
vs2003 and link it with dlls build with vs2005, the build is
successful but at runtime i get an error "could not find msvcr80.dll".

The easiest way around that is probably to link your DLLs against static
CRT: Project | Properties | C/C++ | Code Generation | Runtime Library =
Multithreaded (or Multithreaded Debug, when doing debug build).
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[Igor Tandetnik]

<ye***@yahoo.co m> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com

Some dlls export C API, and others export C++. But i would think if
there was a problem with C++ name decoration, i would get a different
kind of error, like "symbol not found".
You just don't get that far. Once you overcome the CRT DLL hurdle,
you'll be hit by this problem.
I guess linking dlls with runtime statically would probably solve the
problem, but it would also make the footprint much bigger since all
runtime library code would have to be contained in each dll.

Any other way to do it?
Does your DLL have a manifest bound to it as a resource (to check, open
the DLL with resource editor)? It should look something like this:

<assembly xmlns="urn:sche mas-microsoft-com:asm.v1"
manifestVersion ="1.0">
<dependency>
<dependentAssem bly>
<assemblyIdenti ty type="win32" name="Microsoft .VC80.CRT"
version="8.0.50 727.42" processorArchit ecture="x86"
publicKeyToken= "1fc8b3b9a1e18e 3b"></assemblyIdentit y>
</dependentAssemb ly>
</dependency>
</assembly>

My understanding is that, with the correct manifest, it should just
work. But I really know very little on the subject. Hopefully, somebody
more knowlegeable will chime in at this point.
Also, seems like java apps cannot use vs2005 dlls?

I don't think Java apps particularly care about your build tool, as long
as the DLL exports all the right functions. It's probably the same
problem with msvcr80.dll
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[yevvi]

Hi,
I found out that my dlls didnt contain manifest embedded in them, but
instead had .manifest files in the same directory. I embeded those
manifests into the dlls by running mt.exe /manifest file.dll.manife st
/outputresource: file.dll.
Unfortunately it still doesn't fix the problem. One thing i saw is
that .manifest files specify different version of runtime libraries
from the one installed in WinSxS folder. I tried to edit manifest
files to include the installed version instead, but it still doesn't
help. Would different versions cause problems? Anything else i might
be doing wrong?

Thanks
Yev

Igor Tandetnik wrote:

<ye***@yahoo.co m> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com

Some dlls export C API, and others export C++. But i would think if
there was a problem with C++ name decoration, i would get a different
kind of error, like "symbol not found".

You just don't get that far. Once you overcome the CRT DLL hurdle,
you'll be hit by this problem.

I guess linking dlls with runtime statically would probably solve the
problem, but it would also make the footprint much bigger since all
runtime library code would have to be contained in each dll.

Any other way to do it?

Does your DLL have a manifest bound to it as a resource (to check, open
the DLL with resource editor)? It should look something like this:

<assembly xmlns="urn:sche mas-microsoft-com:asm.v1"
manifestVersion ="1.0">
<dependency>
<dependentAssem bly>
<assemblyIdenti ty type="win32" name="Microsoft .VC80.CRT"
version="8.0.50 727.42" processorArchit ecture="x86"
publicKeyToken= "1fc8b3b9a1e18e 3b"></assemblyIdentit y>
</dependentAssemb ly>
</dependency>
</assembly>

My understanding is that, with the correct manifest, it should just
work. But I really know very little on the subject. Hopefully, somebody
more knowlegeable will chime in at this point.

Also, seems like java apps cannot use vs2005 dlls?

I don't think Java apps particularly care about your build tool, as long
as the DLL exports all the right functions. It's probably the same
problem with msvcr80.dll
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

copy files from %VS80COMNTOOLS% \..\..\vc\redis t\x86\ to the same directory
as your DLL may fix your problem.

<ye***@yahoo.co m> wrote in message
news:11******** *************@f 14g2000cwb.goog legroups.com...

Hi,
I found out that my dlls didnt contain manifest embedded in them, but
instead had .manifest files in the same directory. I embeded those
manifests into the dlls by running mt.exe /manifest file.dll.manife st
/outputresource: file.dll.
Unfortunately it still doesn't fix the problem. One thing i saw is
that .manifest files specify different version of runtime libraries
from the one installed in WinSxS folder. I tried to edit manifest
files to include the installed version instead, but it still doesn't
help. Would different versions cause problems? Anything else i might
be doing wrong?

Thanks
Yev

Igor Tandetnik wrote:

<ye***@yahoo.co m> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com

> Some dlls export C API, and others export C++. But i would think if
> there was a problem with C++ name decoration, i would get a different
> kind of error, like "symbol not found".

You just don't get that far. Once you overcome the CRT DLL hurdle,
you'll be hit by this problem.

> I guess linking dlls with runtime statically would probably solve the
> problem, but it would also make the footprint much bigger since all
> runtime library code would have to be contained in each dll.
>
> Any other way to do it?

Does your DLL have a manifest bound to it as a resource (to check, open
the DLL with resource editor)? It should look something like this:

<assembly xmlns="urn:sche mas-microsoft-com:asm.v1"
manifestVersion ="1.0">
<dependency>
<dependentAssem bly>
<assemblyIdenti ty type="win32" name="Microsoft .VC80.CRT"
version="8.0.50 727.42" processorArchit ecture="x86"
publicKeyToken= "1fc8b3b9a1e18e 3b"></assemblyIdentit y>
</dependentAssemb ly>
</dependency>
</assembly>

My understanding is that, with the correct manifest, it should just
work. But I really know very little on the subject. Hopefully, somebody
more knowlegeable will chime in at this point.

> Also, seems like java apps cannot use vs2005 dlls?

I don't think Java apps particularly care about your build tool, as long
as the DLL exports all the right functions. It's probably the same
problem with msvcr80.dll
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

[Carl Daniel [VC++ MVP]]

www.fruitfruit.com wrote:

copy files from %VS80COMNTOOLS% \..\..\vc\redis t\x86\ to the same
directory as your DLL may fix your problem.

No, don't do that. For CRT DLLs to work side by side, the EXE has to have a
manifest, something the OP is trying to avoid.

-cd

[Carl Daniel [VC++ MVP]]

ye***@yahoo.com wrote:

Hi,
I found out that my dlls didnt contain manifest embedded in them, but
instead had .manifest files in the same directory. I embeded those
manifests into the dlls by running mt.exe /manifest file.dll.manife st
/outputresource: file.dll.
Unfortunately it still doesn't fix the problem. One thing i saw is
that .manifest files specify different version of runtime libraries
from the one installed in WinSxS folder. I tried to edit manifest
files to include the installed version instead, but it still doesn't
help. Would different versions cause problems? Anything else i might
be doing wrong?

The "wrong" version in the manifest file is correct. There's a policy file
in the WinSxS directory that directs that version to the correct, finaly
verion of the DLLs.

You're probably embeddeing the manifest in the DLL with the wrong resource
ID. When embedded in an EXE, the manifest must have resource ID 1, but when
embedded in a DLL the ID must be 2.

See this thread for details:

http://groups.google.com/group/micro...e19aa831?hl=en

-cd

[yevvi]

After using resource id 2 it works.

Thanks a lot,
Yev

Carl Daniel [VC++ MVP] wrote:

ye***@yahoo.com wrote:

Hi,
I found out that my dlls didnt contain manifest embedded in them, but
instead had .manifest files in the same directory. I embeded those
manifests into the dlls by running mt.exe /manifest file.dll.manife st
/outputresource: file.dll.
Unfortunately it still doesn't fix the problem. One thing i saw is
that .manifest files specify different version of runtime libraries
from the one installed in WinSxS folder. I tried to edit manifest
files to include the installed version instead, but it still doesn't
help. Would different versions cause problems? Anything else i might
be doing wrong?

The "wrong" version in the manifest file is correct. There's a policy file
in the WinSxS directory that directs that version to the correct, finaly
verion of the DLLs.

You're probably embeddeing the manifest in the DLL with the wrong resource
ID. When embedded in an EXE, the manifest must have resource ID 1, but when
embedded in a DLL the ID must be 2.

See this thread for details:

http://groups.google.com/group/micro...e19aa831?hl=en

-cd