> 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

> 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

> <ye***@yahoo.com> wrote in message
> news:1150235790.543778.179010@u72g2000cwu.googlegroups.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:schemas-microsoft-com:asm.v1"
> manifestVersion="1.0">
>   <dependency>
>     <dependentAssembly>
>       <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
> version="8.0.50727.42" processorArchitecture="x86"
> publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
>     </dependentAssembly>
>   </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

news:1150247254.430129.70330@f14g2000cwb.googlegroups.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.manifest
> /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.com> wrote in message
>> news:1150235790.543778.179010@u72g2000cwu.googlegroups.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:schemas-microsoft-com:asm.v1"
>> manifestVersion="1.0">
>>   <dependency>
>>     <dependentAssembly>
>>       <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
>> version="8.0.50727.42" processorArchitecture="x86"
>> publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
>>     </dependentAssembly>
>>   </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
>

> 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.manifest
> > /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/microsoft.public.dotnet.languages.vc/msg/e84703d4e19aa831?hl=en
>
> -cd