 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / June 2006Can we use dlls build with VS2005 with old apps?
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 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 > Hi, > [quoted text clipped - 20 lines] > Thanks a lot, > Yev > 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).  SignatureWith 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 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 > > My question is, can previously built apps use my new dlls build with > > vs2005? [quoted text clipped - 20 lines] > land, and it could be dangerous sitting under them as they fly > overhead. -- RFC 1925 > 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 SignatureWith 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 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 > > 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 [quoted text clipped - 40 lines] > land, and it could be dangerous sitting under them as they fly > overhead. -- RFC 1925 copy files from %VS80COMNTOOLS%\..\..\vc\redist\x86\ to the same directory as your DLL may fix your problem. > Hi, > I found out that my dlls didnt contain manifest embedded in them, but [quoted text clipped - 55 lines] >> land, and it could be dangerous sitting under them as they fly >> overhead. -- RFC 1925 > copy files from %VS80COMNTOOLS%\..\..\vc\redist\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 > Hi, > I found out that my dlls didnt contain manifest embedded in them, but [quoted text clipped - 7 lines] > 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/e84703d4 e19aa831?hl=en -cd After using resource id 2 it works. Thanks a lot, Yev > > Hi, > > I found out that my dlls didnt contain manifest embedded in them, but [quoted text clipped - 21 lines] > > -cd Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.