473,573 Members | 3,267 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Manifests and VC8

I have just installed VS2005 RTM on a machine that has *never* had any
of the beta versions. It did have VS2003, but I uninstalled that.

I built a DLL with the new managed C++ syntax. The linker generated a
manifest, so far so good. The manifest says that there is a dependency
to Microsoft.VC80. CRT version 8.0.50608.0. (Note that I do not
explicitly use the CRT, the compiler is adding the dependency, but that
is not the issue in this post.)

When I run a process that uses this DLL I get a FileNotFoundExc eption.
%windir%\WinSxS does not have an entry for this particular version. The
nearest I can find is

x86_Microsoft.V C80.CRT_1fc8b3b 9a1e18e3b_8.0.5 0727.42_x-ww_f75eb16c

Note that the only difference between this and the reference in the
manifest is the version. (The public key token is the same.) So why is
link version 14.00.50727.42 creating a manifest to an unmanaged that
does not, and has never, existed on my machine?

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 17 '05 #1
19 4070
Richard Grimes wrote:
I have just installed VS2005 RTM on a machine that has *never* had any
of the beta versions. It did have VS2003, but I uninstalled that.

I built a DLL with the new managed C++ syntax. The linker generated a
manifest, so far so good. The manifest says that there is a dependency
to Microsoft.VC80. CRT version 8.0.50608.0. (Note that I do not
explicitly use the CRT, the compiler is adding the dependency, but
that is not the issue in this post.)

When I run a process that uses this DLL I get a FileNotFoundExc eption.
%windir%\WinSxS does not have an entry for this particular version.
The nearest I can find is

x86_Microsoft.V C80.CRT_1fc8b3b 9a1e18e3b_8.0.5 0727.42_x-ww_f75eb16c

Note that the only difference between this and the reference in the
manifest is the version. (The public key token is the same.) So why is
link version 14.00.50727.42 creating a manifest to an unmanaged that
does not, and has never, existed on my machine?


Interesting.

I just did a quick test, creating a C++ class library and a C# app that uses
that library. The app runs just fine, but examining the files produced for
the C++ class library, I see a manifest, and that manifest does indeed have
version 50608.0 specifies in it and not version 50727.42.

So there's at least two things here that I don't understand:

1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build number?

I'm going to forward those questions on to the VC++ team - there's something
very fishy going on here.

-cd
Nov 17 '05 #2
Carl Daniel [VC++ MVP] wrote:
Richard Grimes wrote:

Interesting.

I just did a quick test, creating a C++ class library and a C# app
that uses that library. The app runs just fine, but examining the
files produced for the C++ class library, I see a manifest, and that
manifest does indeed have version 50608.0 specifies in it and not
version 50727.42.
So there's at least two things here that I don't understand:

1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build
number?
Here's some more information. I compiled on the command line, with no
pre-compiled headers (/clr /LD /Zi /MDd); I was not using a VS project.
Then I created a VS project for the class library, and compiled for
Debug. I copied this new library into the folder where my app was (a
simple C# process), ran it, and the problems disappeared.

Searching through the VS build output log the difference appears to be
that the VC project embeds the manifest using mt.exe, and I am not doing
this on the command line. So I took the library I created on the command
line and embedded the manifest in it with mt.exe. The library is now
loaded and I don't get any errors.

It seems to me that the managed C++ compiler is useless if it cannot be
used to build a library on the command line. I have been using it since
C/C++ v7 and as far as I can remember I have been able to compile and
link a DLL using just the compiler (cl.exe). Version 14 has broken this,
because to get a library that will load I must massage the DLL with
mt.exe. This is a step backward IMO.
I'm going to forward those questions on to the VC++ team - there's
something very fishy going on here.


Thanks, please do. It appears that as far as anyone on the .NET team is
concerned, I have been ex-communicated. :-(

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 17 '05 #3
"Richard Grimes" <ri******@mvps. org> wrote in message
news:eG******** ******@TK2MSFTN GP12.phx.gbl...
Carl Daniel [VC++ MVP] wrote:
Richard Grimes wrote:

Interesting.

I just did a quick test, creating a C++ class library and a C# app
that uses that library. The app runs just fine, but examining the
files produced for the C++ class library, I see a manifest, and that
manifest does indeed have version 50608.0 specifies in it and not
version 50727.42.
So there's at least two things here that I don't understand:

1. Why the wrong build number in the manifest?
2. Why did it work for me but not for you despite that wrong build
number?


Here's some more information. I compiled on the command line, with no
pre-compiled headers (/clr /LD /Zi /MDd); I was not using a VS project.
Then I created a VS project for the class library, and compiled for Debug.
I copied this new library into the folder where my app was (a simple C#
process), ran it, and the problems disappeared.

Searching through the VS build output log the difference appears to be
that the VC project embeds the manifest using mt.exe, and I am not doing
this on the command line. So I took the library I created on the command
line and embedded the manifest in it with mt.exe. The library is now
loaded and I don't get any errors.

It seems to me that the managed C++ compiler is useless if it cannot be
used to build a library on the command line. I have been using it since
C/C++ v7 and as far as I can remember I have been able to compile and link
a DLL using just the compiler (cl.exe). Version 14 has broken this,
because to get a library that will load I must massage the DLL with
mt.exe. This is a step backward IMO.
I'm going to forward those questions on to the VC++ team - there's
something very fishy going on here.


Thanks, please do. It appears that as far as anyone on the .NET team is
concerned, I have been ex-communicated. :-(


Here's the reply that I got:

<quote>
The version in the external manifest file or the embeded manifest will show
8.0.50608.0 as you indicated. What really happens is that there are policies
at the WinSxS\policies directory that maps such version to 8.0.50727.42.
That explains why it works even when you are seeing the different version in
the manifest generated.

For example building a simple a.cpp application with /MD will generate a
manifest containing
<assemblyIdenti ty type='win32' name='Microsoft .VC80.CRT'
version='8.0.50 608.0' processorArchit ecture='x86'
publicKeyToken= '1fc8b3b9a1e18e 3b' />

Whe you run the application the policy on my machine at
%windir%\WinSxS \Policies\x86_p olicy.8.0.Micro soft.VC80.CRT_1 fc8b3b9a1e18e3b _x-ww_77c24773\8.0 .50727.4
2.policy (which contains the below) will direct the binary to the new
version
<assemblyIdenti ty type="win32" name="Microsoft .VC80.CRT"
processorArchit ecture="x86" publicKeyToken= "1fc8b3b9a1e18e 3b"/>
<bindingRedirec t oldVersion="8.0 .41204.256-8.0.50608.0"
newVersion="8.0 .50727.42"/>

The policy directs a certain range of versions to the newer version manifest
at the SxS directroy.
</quote>

Looking on my machine, I have a file

8.0.50727.26.po licy

in directory

C:\WINDOWS\WinS xS\Policies\x86 _policy.8.0.Mic rosoft.VC80.Deb ugCRT_1fc8b3b9a 1e18e3b_x-ww_09e017b4

that remaps the 50608.0 build to the correct assembly (I'm using RC1 instead
of RTM, which is why mine say .26 instead of .42).

Perhaps that policy is missing/wrong on your machine?

-cd
Nov 17 '05 #4
Carl,

Perhaps that policy is missing/wrong on your machine?


No I have the policy file and it contains the right information.
However, in my last post I identified what I think is the real reason
for the file load error in the original post.

I compiled at the command line and hence the manifest appeared in a
separate file. The documentation says that the side-by-side mechanism
should prefer the file to an embedded resource 'manifest'. However this
does not seem to be the case, the Win32 'assembly' will not be loaded.
If I embed the 'manifest' in the .NET assembly file (I wished SxS hadn't
decided to overload assembly and manifest) then the Win32 file is
correctly loaded.

Also, it seems odd to provide a policy file in this situation. Why
didn't they just issue a new version of the 'assemblies' for the RTM of
VS?

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 17 '05 #5
Hi Richard,
I am the one who actually posted the reply to Carl in his latest reply.

For dlls, you will have to embed the manifest into your dll. I can hook you
up with the Libraries folks if you need more info on why you need to do so.

Thanks,
Ayman

"Richard Grimes" wrote:
Carl,

Perhaps that policy is missing/wrong on your machine?


No I have the policy file and it contains the right information.
However, in my last post I identified what I think is the real reason
for the file load error in the original post.

I compiled at the command line and hence the manifest appeared in a
separate file. The documentation says that the side-by-side mechanism
should prefer the file to an embedded resource 'manifest'. However this
does not seem to be the case, the Win32 'assembly' will not be loaded.
If I embed the 'manifest' in the .NET assembly file (I wished SxS hadn't
decided to overload assembly and manifest) then the Win32 file is
correctly loaded.

Also, it seems odd to provide a policy file in this situation. Why
didn't they just issue a new version of the 'assemblies' for the RTM of
VS?

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

Nov 17 '05 #6
Nevertheless, please feel free to log a suggenstion issue at
http://lab.msdn.microsoft.com/produc...k/default.aspx if you want
cl.exe or link.exe to do that for your in future releases.

Thanks,
Ayman

"Ayman Shoukry [MSFT]" wrote:
Hi Richard,
I am the one who actually posted the reply to Carl in his latest reply.

For dlls, you will have to embed the manifest into your dll. I can hook you
up with the Libraries folks if you need more info on why you need to do so.

Thanks,
Ayman

"Richard Grimes" wrote:
Carl,

Perhaps that policy is missing/wrong on your machine?


No I have the policy file and it contains the right information.
However, in my last post I identified what I think is the real reason
for the file load error in the original post.

I compiled at the command line and hence the manifest appeared in a
separate file. The documentation says that the side-by-side mechanism
should prefer the file to an embedded resource 'manifest'. However this
does not seem to be the case, the Win32 'assembly' will not be loaded.
If I embed the 'manifest' in the .NET assembly file (I wished SxS hadn't
decided to overload assembly and manifest) then the Win32 file is
correctly loaded.

Also, it seems odd to provide a policy file in this situation. Why
didn't they just issue a new version of the 'assemblies' for the RTM of
VS?

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

Nov 17 '05 #7
Hi Ayman,
I am the one who actually posted the reply to Carl in his latest
reply.

For dlls, you will have to embed the manifest into your dll. I can
hook you up with the Libraries folks if you need more info on why you
need to do so.


Thanks. I would like to know why the manifest has to be embedded. I am
writing about compiling .NET libraries with C++ and will publish it
here:

http://www.grimes.demon.co.uk/workshops/fusWSTwelve.htm

So it would be nice to give a definitive reason.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

Nov 17 '05 #8
Hi,

DLLs have to have manifest embedded inside. It was a decision made by
Windows team that LoadLibrary() ignores external manifest for DLLs and loads
a DLL in activation context of the loader. To activate context of the DLL, it
has to have manifest embedded inside DLL with ID==2.

As for why linker does not embedd manifest, this is another question. There
are number of reasons why we did not do this in VS2005, however I think this
may be changed in the next release. This is certainly a feature on the top of
our list for the next release.

Nikola
VC++

"Richard Grimes" wrote:
Hi Ayman,
I am the one who actually posted the reply to Carl in his latest
reply.

For dlls, you will have to embed the manifest into your dll. I can
hook you up with the Libraries folks if you need more info on why you
need to do so.


Thanks. I would like to know why the manifest has to be embedded. I am
writing about compiling .NET libraries with C++ and will publish it
here:

http://www.grimes.demon.co.uk/workshops/fusWSTwelve.htm

So it would be nice to give a definitive reason.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

Nov 17 '05 #9
Hi Nikola,

Thanks.
DLLs have to have manifest embedded inside. It was a decision made by
Windows team that LoadLibrary() ignores external manifest for DLLs
and loads a DLL in activation context of the loader. To activate
context of the DLL, it has to have manifest embedded inside DLL with
ID==2.
Indeed. So the rules have changed. OK, I can accept that, but it would
have been better if the OS people had made it more well known. Can you
get the documentation changed:

http://msdn.microsoft.com/library/en..._manifests.asp

says:
Assembly manifests can be installed in three locations:

[snip]
a.. As manifests that accompany private assemblies, assembly manifests
should installed in the directory structure of the application. This is
usually a separate file in the same folder as the application's
executable file.
b.. As a resource in a DLL, the assembly is available for the private
use of the DLL. An assembly manifest cannot be included as a resource in
an EXE. An EXE file may include an application manifest as a resource.
This clearly says that a separate file is acceptable. Also:

http://msdn.microsoft.com/library/en...g_sequence.asp

says:

The first time side-by-side searches for a private assembly, it
determines whether a language-specific subfolder exists in the
application's directory structure. If no language-specific subfolder
exists, side-by-side searches for the private assembly in the following
locations using the following sequence.
1.. Side-by-side searches the WinSxS folder.
2.. \\<appdir>\<ass emblyname>.DLL
3.. \\<appdir>\<ass emblyname>.mani fest
4.. \\<appdir>\<ass emblyname>\<ass emblyname>.DLL
5.. \\<appdir>\<ass emblyname>\<ass emblyname>.mani fest
etc etc (this page keeps saying that the manifest file will be used if a
bound unmanaged resource is not available).

Also while you are talking to the MSDN documention people could you get
them to document *all* of the switches for mt.exe?

Frankly, this page is pathetic:

http://msdn.microsoft.com/library/en...tup/mt_exe.asp

mt /?

at the command line gives pages of switches.
As for why linker does not embedd manifest, this is another question.
There are number of reasons why we did not do this in VS2005, however
I think this may be changed in the next release. This is certainly a
feature on the top of our list for the next release.


That is good news. I am sure I am like most C++ developers, I expect the
C++ compiler/linker to compile my code and work straightaway, just as it
did with the last version of the compiler/linker. This does not happen
with the current version and in my opinion that is a 'feature' that
should not have occurred.

It would have been less bad if the linker had a
create-manifest-but-don't-link option so that I could call the linker
once to create the manifest, generate a resource script and compile it,
and then call the linker again to create the pe file. Calling the linker
twice just feels wrong. However, manipulating the output of the linker
with mt.exe feels even more wrong.

Anyway, I have written up the process of handling manifest files in both
managed and unmanaged code and they will appear on this page in a day or
two:

http://www.grimes.demon.co.uk/worksh...WSThirteen.htm

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Nov 18 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1320
by: Wayne | last post by:
Can anyone cast any light on the following. I have a database that I have written in Access 2003 using 2000 file format. Everything was working OK when running it under Access 2003 but when I tried running it under Access 2000 if fell over when I tried to open some of the reports. I then tried opening it in Access 2003 again and it brought...
0
1082
by: Jeff S | last post by:
I'm trying to more fully understand how .NET gets us out of dll hell by more clearly understanding what goes into the manifest and contrasting that with and what life was like before the manifest. Specifically, I would like to know why COM components need to be registered in the Windows System Registry. Registering COM components has been a...
0
1064
by: Marc Gravell | last post by:
OK heres an oddity... I am using a ClickOnce (online only) deployment model; I have various servers (primarily for different environments: testing, production etc), and I want to have a *similar* manifest on each, with the main difference being the config file (so that each connects to appropriate servers). To get around the hashing on the...
0
884
by: Neil P | last post by:
Hi all, I'm currently working on an application with a plug-in architecture, and want to be able to deploy the application and plug-ins seperately and have them update a ClickOnce manifest on a customer's server whenever a plug-in is installed. I've noticed that manifest always have to detail every DLL being used, which means it has to be...
0
1801
by: Raffi Basmajian | last post by:
I am trying to understand the difference between signing ClickOnce manifests and signing shared assemblies. My company is building .Net 2005 WinForm applications for internal company use only. Currently, the ClickOnce security settings on the applications is set for "Full Trust". We are using shared assemblies across development groups, but...
0
951
by: drkato | last post by:
Hi there. I have an application that consists of the EXE and a number of support DLLs. When I build all of these components, all of my projects direct their binary output to a 'bin' folder (not to the default location). After upgrading the solutions and projects from VC 2003 to VC 2005, I can no longer run the EXE (in fact, during my builds,...
4
1262
by: jkanski | last post by:
Hi everyone I need to embed an UAC manifest into my application to meet the Vista Logo requirements but I want also to protect my source code. When I embed a manifest into a protected .exe file I cannot run the application anymore. Should I embed the manifest before obfuscating? Will Vista be able to see the manifest then? I use...
0
1008
by: =?Utf-8?B?QWxiZXJ0byBDYXJkb3Nv?= | last post by:
Im creating a clickonce application... Im not using VS2005 to publish it, im using the mage.exe wich is a DOS programa and is not very friendly. Is there a library or some set of classes that creates .manifests, ..applications and sign them with a security key? I saw the System.deployment.application but I only sow examples that show how...
1
2537
by: Marcin Balcerzak | last post by:
Hello, I'm lame when it comes to .Net and Office and unfortunatelly need to run a VS project. When run it should start Excel and open some sheet. What I now get is "System policy prevents loading manifests. For more information, please contact your administrator." It used to be more 'sophisticated' error (something about assemblies, whatever...
0
7661
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8165
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
0
8026
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6347
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5550
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5252
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3692
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3686
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1256
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.