Problems with release version of C++ Web Service

  • Thread starter Thread starter Russ
  • Start date Start date
R

Russ

I have a Web Service that was originally created with .NET VC 2003,
and subsequently converted to the 2005 version. It works fine when
built as a debug version, and run on the workstation it was built on.
Now I want to build a release version so I can deploy it to Windows
2003 server. This project is compiled with "/clr:oldSystax". I've
run into several problems and I am not sure all of the things I am
discovering are related. Any help I can get to understand what is
going on would be much appreciated.

First I changed the project to release version, and changed all input
libraries to point to the release versions of the C++ DLL's that the
WS depends upon. The project builds and deploys to the local machine
with no problem. But when I try to run it I get the infamous debug
screen that tells you nothing...except "The specified module could not
be found".

Running Filemon, it becomes clear that the module in question is
MFC80.DLL. That is strange because this is the dev machine, and sure
enough the MFC80 libraries are installed in the Win SxS directories.
But checking the web service DLL with Depends, sure enough it can't
find MFC80! The reason it depends on MFC80 is that it is linked to
release C++ (unmanaged) DLL's that use MFC80.

So, I tried using the debug version of the web service with the
release C++ DLL's, and it works fine.

Then I checked the debug version with depends and it
shows the same thing - it depends on MFC80, and it also cannot be
found. So I checked the debug version with Filemon and surprise,
MFC80 is never looked for. Next I checked the release
intermediate.manifest file and the MFC80 libraries are not in it.

So... WHY do both versions depend upon MFC80 according to Depends, but
only the release version actually tries to open it?

And... If the release version does reqire MFC80, why is it not in the
manifest?

And... how can I fix the release version?

HELP Please!

Thanks, Russ
 
Hi Russ,

Russ said:
I have a Web Service that was originally created with .NET VC 2003,
and subsequently converted to the 2005 version. It works fine when
built as a debug version, and run on the workstation it was built on.
Click to expand...

Did you install vcredist on the target machine? Remember that two versions
exist: one for 2005 RTM and one for SP1. So the version you need depends on
your VS2005 you build your dlls with
Now I want to build a release version so I can deploy it to Windows
2003 server. This project is compiled with "/clr:oldSystax". I've
run into several problems
Click to expand...
Running Filemon, it becomes clear that the module in question is
MFC80.DLL.
Click to expand...

How does this become clear?
In which directories the mfc80.dll is searched and not found?
That is strange because this is the dev machine, and sure
enough the MFC80 libraries are installed in the Win SxS directories.
Click to expand...

Could it be that another version of mfc80.dll is already loaded into the
process hosting the WebService? Is it hosted in IIS? So it would be
w3wp.exe. You might want to check that process with ProcessExplorer and see
which dlls are already loaded. I would expect that only one version of
mfc80.dll can be loaded at one time, so if the RTM version is already loaded
and your dll needs the SP1 version you could be in trouble.
But checking the web service DLL with Depends, sure enough it can't
find MFC80! The reason it depends on MFC80 is that it is linked to
release C++ (unmanaged) DLL's that use MFC80.
Click to expand...

Which version of Depends do you use? I found that older versions do not know
how to deal with WinSXS. I use Depends 2.2 which seems to be OK.
So, I tried using the debug version of the web service with the
release C++ DLL's, and it works fine.
Click to expand...

Hmm, strange.
Then I checked the debug version with depends and it
shows the same thing - it depends on MFC80, and it also cannot be
found. So I checked the debug version with Filemon and surprise,
MFC80 is never looked for. Next I checked the release
intermediate.manifest file and the MFC80 libraries are not in it.
Click to expand...

What is your setting under Project->Properties->Config->General : "Use of
MFC"?
Remember that those settings are individually saved each Config, e.g.
Release and Debug. So make sure that all configs are in sync.

How are the config settings for Manifest Tool->Input and Output? Any
differences between Release and Debug config?
So... WHY do both versions depend upon MFC80 according to Depends, but
only the release version actually tries to open it?

And... If the release version does reqire MFC80, why is it not in the
manifest?
Click to expand...

You might want to try to create a new WebService project created by the VC++
wizard of VS2005 and compare the settings with your upgraded project. Maybe
something was messed up when you upgraded from 2003 to 2005?
 
SvenC, thanks for your comments. I have been working on this and
other problems for a week or so in my spare time. I finally got the
release web service working on my test W2003 server. There were
multiple issues making it hard to tell when an applied change made an
improvement. However the main thing with regards to release version
is that it is necessary for me to put MFC80.DLL somewhere in the
environment path. (For now, I placed it into the bin directory of the
web service, and then modified path statement on the server to include
the bin folder. After reboot the web service now runs.)

This still leaves some questions, as I somehow doubt this is the way
things are suppled to work. Here is one thing I noticed...

Using the latest version of Depends, when I examine the release
version of any of my C++ DLL's, it clearly shows that MFC80 is found
in the proper Side by Side folder. This is not surprising since MFC80
is in the manifest for those libraries. But as stated before, running
the web service, the SxS folders are not searched for MFC80 (because
MFC80 is not in the manifest for the web service). It now finds it in
the bin directory where I put it, and it seems happy to examine it and
then continue loading, where before it stopped loading because it was
not found.

Now, given that the web service links to several of the C++ DLL's that
link MFC80, why would not the web service automatically include MFC80
in it's manifest? Is this a bug in the way VC++ builds a C++ web
service? Could it be that this only happens if the web service is
complied with /clr:Oldsyntax? Can anyone answer these questions?

Thanks, Russ
 
SvenC, thanks for your comments. I have been working on this and
other problems for a week or so in my spare time. I finally got the
release web service working on my test W2003 server. There were
multiple issues making it hard to tell when an applied change made an
improvement. However the main thing with regards to release version
is that it is necessary for me to put MFC80.DLL somewhere in the
environment path.
...
Now, given that the web service links to several of the C++ DLL's that
link MFC80, why would not the web service automatically include MFC80
in it's manifest? Is this a bug in the way VC++ builds a C++ web
service? Could it be that this only happens if the web service is
complied with /clr:Oldsyntax? Can anyone answer these questions?
Click to expand...

I just made a test project ASP.Net Web Service with VS2005 SP1.
By default CLR was set to pure, so using MFC was not possible.
Changing it to oldSyntax gave me errors on the wizard created WebService
which is obvious as the wizard creates C++/CLI. As I do know MC++ enough I
didn't try to convert it to MC++ but instead used the /clr switch for the
new syntax. I added a CString in one place, built the project and have got a
manifest with an MFC reference.

So you might be correct with assuming a bug related to oldSyntax. You might
want to take this as a "good" reason for switching to C++/CLI. If you are
under time pressure you could use a #pragma to add the MFC dependency
manually:

http://msdn2.microsoft.com/en-us/library/ew0y5khy(VS.80).aspx
 
Back
Top