asked on

C++, Microsoft Visual Studio 6.0 - Compiler issue

OK, probably an easy question. I've got Visual Studio 6.0 installed, and some sample code provided to me, which SHOULD compile, since I haven't made any changes as yet. The code given to me has an include folder, which I have added to my list of include folders. When I compile, here is what I see:
--------------
Deleting intermediate files and output files for project 'ICAddSub - Win32 Release'.
--------------------Configuration: ICAddSub - Win32 Release--------------------
Creating Type Library...
Processing D:\Ext Toolkit\Samples\FactoryObjects\ICAddSub\ICAddSub.idl
ICAddSub.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\oaidl.idl
oaidl.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\objidl.idl
objidl.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\unknwn.idl
unknwn.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\wtypes.idl
wtypes.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\ocidl.idl
ocidl.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\oleidl.idl
oleidl.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\servprov.idl
servprov.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\urlmon.idl
urlmon.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\msxml.idl
msxml.idl
Processing ..\..\..\include\icontrol.idl
icontrol.idl
Processing ..\..\..\include\IError.idl
IError.idl
Processing ..\..\..\include\IFaceRT.idl
IFaceRT.idl
Processing D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\time.h
time.h
Processing ..\..\..\include\ISymbol.idl
ISymbol.idl
Compiling resources...
Compiling...
StdAfx.cpp
Compiling...
ICAddSub.cpp
ICAddSubObj.cpp
ICAddSubPPG.cpp
Generating Code...
Linking...
Creating library Release/ICAddSub.lib and object Release/ICAddSub.exp
Registering Factory Object
The system cannot find the path specified.
Error executing c:\windows\system32\cmd.exe.

ICAddSub.dll - 1 error(s), 0 warning(s)
-------------
Here are the commands and output from the Custom Build tab:

Commands
--------------
regsvr32 /s /c "$(TargetPath)"
echo regsvr32 exec.time > "$(OutDir)\regsvr32.trg"

Outputs
----------
$(OutDir)\regsvr32.trg

I'm stuck from here. What should I be looking at next?

itsmeandnobodyelse

>>>> $(OutDir)\regsvr32.trg

It looks like it doesn't resolve the macros.

Could you add

echo $(TargetPath)

to verify that. If a valid path was outputted you might check whether there actually is a file to register there

JasonGreff

ASKER

OK, so I have this new line in the response

\Ext Toolkit\Samples\FactoryObjects\ICAddSub

This is a valid path, just needs a "D:" in front of it. Newbie here, where are $(TargetPath) and $(OutDir) set?

JasonGreff

ASKER

By the way, using echo $(OutDir) gives me
.\Release

RegSvr32.trg doesn't exist anywhere. It appears that I'm attempting to register it before it gets created? Or am I missing something obvious here?

itsmeandnobodyelse

>>>> This is a valid path,
Ok, open a command window (dos box), change directory to the project folder and type

regsvr32 /c "\Ext Toolkit\Samples\FactoryObjects\ICAddSub"

If I am right you should get the same error message "The system cannot find the path specified."

>>>> just needs a "D:" in front of it.
Is the project directory at a different drive than the \Ext Toolkit\... path?

>>>> echo regsvr32 exec.time > "$(OutDir)\regsvr32.trg"
That statement was supposed to stream the string "regsvr exec.time" to the file ".Release\regsvr32.trg". If you don't find such a file in .Release it most likely is because the regsvr32 failed before.

>>>> It appears that I'm attempting to register it before it gets created?
No, you try to register the result of the build what should be the ICAddSub.dll or ICAddSub.ocx, or any other library. What I wonder is why the $(TargetPath) has no file extension? Do you know what is the result of the build and can you check whether it was successfully built?

JasonGreff

ASKER

I opened a command prompt and went to the following path:

D:\Ext Toolkit\Samples\FactoryObjects\ICAddSub

Then I typed in regsvr32 /c "\Ext Toolkit\Samples\FactoryObjects\ICAddSub"

The response is "Load Library("...") failed - The specified module could not be found."

OK, here's my directory structure. I have a Workspace created within D:\Ext Toolkit\Samples. Inside of that directory are multiple subfolders, but the important one is "FactoryObjects". Within that are three more subfolders. Each of these contains code for some classes that are built in the workspace. One of these classes is ICAddSub, and within that subfolder there are both a release folder and a debug folder. I hope this is enough detail for what you are looking for.

The end result should be ICAddSub.dll, which is not appearing in the "Release" folder, instead, it is one level up, in the ICAddSub folder. And yes, each time I do a build the file date changes.

itsmeandnobodyelse

>>>> "Load Library("...") failed - The specified module could not be found."
That means that the ICAddSub was dependent on some dll or other library which wasn't available at this place. You could solve that issue by adding the path to the dependent dll to the PATH environment variable. I wonder why you now get a different message than in the studio. Can you check the paths defined in the settings at Tools - Options - Directories - Executables? The same paths should be added to the environment variable Path at system settings - system - advanced - environment variables.

Did you get the same message when repeating the build in the studio?

JasonGreff

ASKER

My path in the OS environment variables is huge due to the large number of applications I have installed in the past. However, there are some directories listed in the C++ directories that are not listed in my OS Path. From the OS Path, I think the following are relevant.

%SYSTEMROOT%\SYSTEM32;
%SYSTEMROOT%;
%SYSTEMROOT%\SYSTEM32\WBEM;

From the C++ directories, the following additional paths are listed
D:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
D:\Program Files\Microsoft Visual Studio\VC98\BIN
D:\Program Files\Microsoft Visual Studio\Common\TOOLS
D:\Program Files\Microsoft Visual Studio\Common\TOOLS\WINNT

So you think I should add these directories to my OS Path? I'm not sure what the dependent dll might be, but I would suspect it is not included in the sample code, it's probably a standard MS dll.

JasonGreff

ASKER

I added the four paths to my OS Path environment variable, it didn't help.

JasonGreff

ASKER

Oh, by the way, I went back and reread some of your posts. I think what you were directing me to do was to attempt to register the dll, which is not what I tried the first time. I specified the path only, not the dll. If I open a command prompt, navigate to the location where the ICAddSub.dll is located, and type

regsvr32 /c ICAddSub.dll

It succeeds.

JasonGreff

ASKER

Here's some interesting information. I can change the Active Configuration between the release version and the debug version. I get the same error either way, but the files that are touched are different. See the attached pictures. I did a compile of the debug configuration at 11:43 and a compile of the release configuration at 11:45. Note that there is an ICAddSub.dll in the Debug folder but not one in the Release folder. There is also an ICAddSub.dll in the main ICAddSub folder, and this only gets touched by the release compile, and not by the debug compile.
Pic1.bmp
pic2.bmp
Pic3.bmp

ASKER CERTIFIED SOLUTION

itsmeandnobodyelse

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

itsmeandnobodyelse

>>>> Here's some interesting information
The differences in the loction of the output dll is defined in the linker settings. Check the linker settings for Release and Debug and you will see that the output once is ./ICAddSub.dll and for the other it is ./Debug/ICAddSub.

I would suggest to change it for the release config accordingly (I already assumed it that way in the command file).

itsmeandnobodyelse

>>>> I added the four paths to my OS Path environment variable, it didn't help.
Yes, the windows and windows\system32 folders are default with or without you adding them to Path or VC settings.

I only wondered why the regsvr32 had problems loading libraries when being started from the project folder. But that is no issue if you could register it probably from the right path.

itsmeandnobodyelse

>>>> you could register it probably

should have been properly.

JasonGreff

ASKER

So essentially what is happening here is that the location of the dll is not the same as the path that the regsvr32 application is operating by default. I'm not sure why this code was structured this way, but this is a very workable solution.