I have been trying to write some scripts to automate a build process in VisualStudio 6.0. The build process builds a number of projects. Some of these projects are just library builds, some of them are builds which result in executable code (.xll, .dll, .exe) I need to be able to change the target directory for the various builds. The scripting method to do this would seem to be
Projects[ i ].Configurations[j].AddToolSettings
(and RemoveToolSettings, etc.) This works fine for the compile settings, i.e. for the "tool" "cl.exe" (as per the documentation).
It also works fine for the linker tool ("link.exe") so long as the build is one which results in an executable, i.e. so long as we are truly linking. However, if I want to control the location and name of the output library when building libraries, I am unable to do this. The libraries are, in reality, built from the object files with the "link.exe -lib ..." command (and not with the executable lib.exe, which claims to simply be a wrapper for "link.exe -lib"). In the .dsp files for the projects, there are 3 "variables" of interest: CPP, LINK32 and LIB32. When building executables, only the CPP and LINK32 variables appear or are relevant. When building libraries, only the CPP and LIB32 variables need be present. Visual Studio sets these as CPP="cl.exe" and LIB32="link.exe -lib". Their actual values, however, are irrelevant: one can set them to CPP="foo" and LIB32="bar", and Visual Studio still spawns, in order, two processes: "cl.exe @fileName.tmp" followed by "link.exe -lib @fileName2.tmp" Now, the problem is that, while
Projects[ i ].Configurations[j].AddToolSettings "cl.exe", "..."
works fine, the command
Projects[ i ].Configurations[j].AddToolSettings "link.exe", "..."
will not work. This latter command does work if one is building a project where the linker is actually linking, i.e. where the spawned command is "link ..." without a -lib option. But when building a library, I cannot get it to work, no matter what string I try to use to replace "link.exe" (e.g. "link.exe -lib",
"link.exe\t-lib",
"lib.exe", ...) and no matter how I assign LIB32 in the .dsp file.
DOES ANYONE KNOW WHAT THE HECK IS GOING ON IN THE BOWELS OF VISUAL STUDIO, AND HOW TO FIX THIS
scripting method AddToolSettings broken in visual Studio 6.0 ????
David Walp - Microsoft
Hi David,
You make some very valid points and rest assured that we understand the difficulties of migrating codebases and as you point out, it's often impossible. Unfortunately, supporting products like Visual Studio becomes exponentially difficult over time for us as well. As Ayman points out, it has been 10 years since we released VC6 and much of its code goes back even further. Since then, we've built 3 new products in a new shell, and much of that codebase is defunct.
Thus, it's actually quite hard for us to even find the part of code where this is happening. The fact is, the developer who owns this area looked at it and could not find this information (and he is by far the most familiar with this code). I agree that this may not be a good state of affairs but it is the unfortunate situation when we try to innovate at the pace that we do.
I would rather try to spend the time to solve your numerical differences between VC6 and VC6+, which is something we have experience with and could simplify your situation greatly.
Thanks,
AlexSl
So, was there a previous bug report on this issue If so, what is the reference or where can I find it And were there any solutions or work-arounds Thanks.
Graham Judd
When we talk about Visual Studio, we usually talk about the IDE used for J++ in 6.0, and the IDE that all the products are in for 7.0 on. But this is a question specific to the Visual C++ IDE from 6.0. Since this is specific to VC, we are going to move it to one of those forums.
Craig
aoeu aoeu oeuaoeu
Um, that was the bug I posted about this question, as referenced in the very first line of the very first post of this thread, which I started to try to get someone at MS to look at this issue. Note that (a) no one has posted any comment in this thread except to claim that the functionality doesn't exist in VC6, which it does, and (b) no one at MS has looked at my initial bug report, so far as I can tell. In short, nothing has been accomplished except a bit of run-around.
Vivek Uppal
If this is a VC6.0 bug then I don't believe it is going to be fixed. The support for VC6.0 officially expired. Nevertheless, I will dig the bug in our bug databse and ping the owner.
Thanks, Ayman Shoukry VC++ Teamcdbrown
What I am trying to explain to you is that folks won't even look at the issue if it is already fixed in later versions of the product. They will probably ask you to try a later version. The place where you reported the bug is only for VS8.0 and probably they will try it there and if tit is fixed, they will just resolve the bug as not repro.
The short answer is that if it is a blocking issues for you in VC6.0, then you still won't get it fixed in that version.
Having this post marked as answered or not won't help since you already did the correct thing by logging the bug which takes higher priority than these forums any ways.
Nevertheless, I will try myself to make get in contact with the person who will look into the issue and get more details if I can (You made me curious about the issue as well :-))
Thanks, Ayman Shoukry VC++ TeamLockyBoy1
Hi David,
I believe the support is not strictly by the number of versions you release. It is for sure a factor but generaly it is around 10 years. Also, we have released 3 versions of VS after. VS2002, VS2003, & VS2005. In your opinion, how long should we support a product
Any ways, Boris from the IDE team started looking at the issue. Take a look your bug link.
Thanks, Ayman Shoukry VC++ Teamedgar.i.sanchez
Ricky Kelley
Thanks for your reply.
I understand that folks at MS might not want to look at it if it is fixed in later versions, but MS must understand that switching versions may not always be an option. In my case, we have a library of complex derivatives pricing code, and small numerical differences in generated code can make noticable differences in end results. While I can easily compile my code in later versions, the resulting prices change. While this is not your issue, it means that I must maintain, for some time, my code using v6.0. In fact, we maintain our code in 6.0 AND later versions, so it's not a reluctance to buy a later version or to make the necessary conversions. It's just not an option to not maintain it in 6.0 for the next while.
Well, I could not find anywhere to report the bug for version 6.0, and I presume that this is because 6.0 is no longer supported. This is a big issue: if MS cannot support its products past two new version releases, then I must say that I am very disappointed in such a short level of support. It makes me think long and hard about why we are using a Microsoft product.
I am happy if someone who has access to the code would just look into the issue and find out exactly why this is happening and get back to me with an explanantion. If they can determine a work-around, great. If not, if I have some information, I may even be able to determine a work-around. See also bug ID FDBK45896. The solution "move to a later version" just isn't that simple.
It only helps in that more people might look at it, and maybe someone has actually discovered a work-around.
OK, thanks. I appreciate it.
chinalifan
I would follow the bug at http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx feedbackid=54dda1dd-cb95-4953-ba7f-d2e3ad7a6057 for workarounds.
Thanks, Ayman Shoukry VC++ TeamShoaib Khot
In the title of this bug, you state that it is a problem with Visual Studio 6.0. But the Configurations object was not available in that version, it was only possible to use Configurations in VS 2002 (version 7.0). Are you sure that you have the versions correct
Craig
Vikram Karumbaiah
OK, this problem has not been answered. Can we stop marking it as answered The only "bug" report refered to here is my bug report, and there has been no reply to it, and I just don't see how saying "I'll see if I can find a bug report" constitutes an "answer" to the problem. If no one can answer the problem, and Microsoft support cannot see fit to support a product only two editions old, that is their choice, but at least lets be honest about things. I'd be happy to move to a newer release, but sometimes that is just not feasable.