- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a simple small DLL which has building with a batch script just fine for a month now. However when I try to build it today depends says it needs MSVCR90.DLL, which for some reason the executable which loads this DLL cannot find. Why it cannot find it is another issue (I have VS 9.0 / Intel 11.060 installed).
But my main question is why was the DLL created yesterday depending on MSVCRT.DLL while todays depends on MSVCR90.DLL?
depends done on yesterday's DLL:
USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCRT.DLL
KERNEL32.DLL
NTDLL.DLL
KERNEL32.DLL
NTDLL.DLL
depends done on today's DLL:
USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCR90.DLL (which it can't find)
KERNEL32.DLL
NTDLL.DLL
Files attached. Yesterday's result of a buildall is in USER directory. Today's result of a buildall is in the USER\\NEW directory.
But my main question is why was the DLL created yesterday depending on MSVCRT.DLL while todays depends on MSVCR90.DLL?
depends done on yesterday's DLL:
USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCRT.DLL
KERNEL32.DLL
NTDLL.DLL
KERNEL32.DLL
NTDLL.DLL
depends done on today's DLL:
USER_KINETICS.DLL
LIBMMD.DLL
KERNEL32.DLL
MSVCR90.DLL (which it can't find)
KERNEL32.DLL
NTDLL.DLL
Files attached. Yesterday's result of a buildall is in USER directory. Today's result of a buildall is in the USER\\NEW directory.
Link Copied
14 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
msvcr90.dll should be present in the visual studio 9.0\vc\redist\ (both 32- and 64-bit versions, if you installed X64). Changes like this, with the necessary directories under \redist\ not coming automatically on PATH, are likely to happen if you change your project setting from static /MT to dynamic /MD, and can be particularly annoying if you don't clean everything when changing the setting. Note Steve's posts about the defaults for C and Fortran not matching.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
msvrc90.dll is present on my c drive in a few Winsxs places. There are 2 issues here:
1. Why can't my dll find msvcr90.dll? That's an issue I need to focus on later, but my main problem is:
2. Why is my build now looking for mscvr90.dll when yesterday it was looking for msvcrt.dll (and was happy as it found it)?
Adrian
1. Why can't my dll find msvcr90.dll? That's an issue I need to focus on later, but my main problem is:
2. Why is my build now looking for mscvr90.dll when yesterday it was looking for msvcrt.dll (and was happy as it found it)?
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
None of the files in the "redist" folder are supposed to be referenced - that folder is for your convenience in locating DLLs to be copied to other systems.
MSVCR90.DLL should be referenced through a manifest, in the shared assembly. You won't find the file by exactly that name. I spent a bit of time on your issue and could reproduce it on my system, building from the command line. I know that if you build from VS, it runs the Manifest Tool that embeds a manifest pointing at the shared assembly. You may have to run mt yourself.
As to why things changed, I'd have to guess that "yesterday" you were linking against a different set of libraries. There's nothing in the ZIP you provided that offers a clue on that.
I had to go look up some of the switches you used - this must be old PowerStation code. /Qfpp1? /LD? Which language calls this DLL?
MSVCR90.DLL should be referenced through a manifest, in the shared assembly. You won't find the file by exactly that name. I spent a bit of time on your issue and could reproduce it on my system, building from the command line. I know that if you build from VS, it runs the Manifest Tool that embeds a manifest pointing at the shared assembly. You may have to run mt yourself.
As to why things changed, I'd have to guess that "yesterday" you were linking against a different set of libraries. There's nothing in the ZIP you provided that offers a clue on that.
I had to go look up some of the switches you used - this must be old PowerStation code. /Qfpp1? /LD? Which language calls this DLL?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info. You say you reproduced the problem: did you create a DLL which depends on MSVCR90.DLL, and that depends.exe cannot find? If so, did you solve the problem? My colleague performed the exact same build as me (on his machine), and depends.exe found the DLL just fine. I'm not sure what settings I need to change on my machine to allow MSVCR90.DLL to be found.
Just before I left the office yesterday, I started a reinstall of VS2008. I won't get a chance to check if that works until June 7 though. I'll probably reinstall IVF 11.1.060 as well.
Yes this code and build process is quite old. It is Fortran all the way through.
Adrian
Just before I left the office yesterday, I started a reinstall of VS2008. I won't get a chance to check if that works until June 7 though. I'll probably reinstall IVF 11.1.060 as well.
Yes this code and build process is quite old. It is Fortran all the way through.
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just a thought, one that may help as a stop-gap measure until you get the MSVCR90.DLL issue sorted out:
You can add /MANIFEST:NO to the linker flags.
You can add /MANIFEST:NO to the linker flags.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I simply built the DLL and depends could not find the DLL - which I sort of expected. Unless you use MT.EXE to embed the manifest, Windows has no idea how to find a shared assembly. Using /manifest:no would require you to copy MSVCR90.DLL from the redist folder into where Windows can find it, but this is not the method I would recommend.
Restating - the way Microsoft wants you to do this is with manifests. Reinstalling VS or IVF will not help.
I did not have enough time to work through a solution - which is likely to run mt.exe to embed the manifest. If you build a DLL in Visual Studio and look at the build log, you'll see what it does. You can then add the commands and options to your command line build. You can read more about manifests at msdn.microsoft.com
I will try to get back to this next week, if you haven't figured it out by then.
Restating - the way Microsoft wants you to do this is with manifests. Reinstalling VS or IVF will not help.
I did not have enough time to work through a solution - which is likely to run mt.exe to embed the manifest. If you build a DLL in Visual Studio and look at the build log, you'll see what it does. You can then add the commands and options to your command line build. You can read more about manifests at msdn.microsoft.com
I will try to get back to this next week, if you haven't figured it out by then.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm pleased that you can reproduce the problem. But this is the method I have used to build DLLs for some time, shouldn't this just work? Like it does for my colleague next door? There must be some setting I need to do on my machine to get the built DLL to find the RT DLL's it needs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know enough about your environment to know why it does/doesn't work. Offhand, I'd say no, it shouldn't work with VS2003 (2005?) or later.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not sure what you mean that it shouldn't work with VS2008. Isn't Intel Fortran 11.1 tested under VS2008 build environment? Why doesn't Intel VF 11.1 work with VS2008? or VS2005 for that matter?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I mean it shouldn't work because when you're referencing a shared assembly, embedding the manifest is required. You're not doing that.
Add this line to your .BAT, after the ifort command that does the link:
mt.exe /nologo /outputresource:user_kinetics.dll;#2 /manifest user_kinetics.dll.manifest
What this does is take the manifest created by the link and embed it in the DLL using resource #2 (for a DLL, this is always #2 - for an EXE it would be #1.)
The version that "worked" was linked using a VS2003 environment, which did not use shared assemblies.
I also recommend removing the "/link /nodefaultlib:library /nodefaultlib:libc.lib" from the ifort command. - you don't need these.
Some general reading on how manifest files are used can be found here.
Add this line to your .BAT, after the ifort command that does the link:
mt.exe /nologo /outputresource:user_kinetics.dll;#2 /manifest user_kinetics.dll.manifest
What this does is take the manifest created by the link and embed it in the DLL using resource #2 (for a DLL, this is always #2 - for an EXE it would be #1.)
The version that "worked" was linked using a VS2003 environment, which did not use shared assemblies.
I also recommend removing the "/link /nodefaultlib:library /nodefaultlib:libc.lib" from the ifort command. - you don't need these.
Some general reading on how manifest files are used can be found here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve, I will check this out when I get back on June 7.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I added the mt.exe line to my batch file, but I still get the error from depends that it can't find MSVCR90.DLL.
So I tried generating the project from scratch- this should work out the box, right?
I created a new project DLL from VC2008, please see attached dll1.zip. I built the DLL, and ran a depends, which shows it still can't find the MSVCR90.DLL
Now this should work, do you know what the problem is?
Adrian
I added the mt.exe line to my batch file, but I still get the error from depends that it can't find MSVCR90.DLL.
So I tried generating the project from scratch- this should work out the box, right?
I created a new project DLL from VC2008, please see attached dll1.zip. I built the DLL, and ran a depends, which shows it still can't find the MSVCR90.DLL
Now this should work, do you know what the problem is?
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You changed some settings in the project - in particular, you set "Use Manifest" to No. That will cause the problem.
Adding the MT line worked for me. What does your new .bat look like?
Adding the MT line worked for me. What does your new .bat look like?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It works now, turns out I was using an older version of depends that didn't know about SxS
Thanks for your help,
Adrian
Thanks for your help,
Adrian

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page