Redistribution of C runtime libraries without MSI installation

Redistribution of C runtime libraries without MSI installation

• MGS21168

  Another update - apologies for the spam here (is it the done thing to edit your posts or to repost with new information btw )
  
  I've found some more info at: ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vccore/html/8d1a994b-9986-4171-9c0b-56d24808fd1f.htm
  
  Especially part 2 (my italics): "On a target computer with manifest-based binding support (Windows XP Home Edition, Windows XP Professional, Windows Server 2003), no further preparation is necessary. On a computer without such support (Windows 95, Windows 98, Windows 98 Second Edition, Windows Millennium Edition, Windows 2000), Microsoft.VC80.CRT and Microsoft.VC80.MFC must be on the path."
  
  So it looks like if I were to use private assemblies; I'd have to path up my VC80.CRT folder somehow during module initialisation - for now, I'm going to just use the redistributable executable!
  
  On another note; I got the 0x80070002 error fixed - that was my own error (oops!) in assembly binding.  A top tip I hadn't seen before - running C:\Program Files\Microsoft Visual Studio 8\sdk\v2.0\Bin\FUSLOGVW.exe helps debug this type of issue.
  
  In closing then; I'm still a bit confused as to why my manifest had to be embedded, I'm now a bit annoyed that were I to use private assemblies I'd have to write different code on pre-WinXP systems (to PATH up the assembly folder), but I've finally gotten my application working (of a sort!).
  
  Thanks again to all those who replied.
  
  Matt
  -==-
  
  
  

• simha

  Martyn Lovell wrote:

  I don't understand your point about 'can't see what gets loaded and what not just looking at a customer's machine' Could you clarify what you are trying to find out

  
  
  After thinking about it, I have to say that there is in deed no problem. Because I define what version should be loaded, I don't have to care from where is is loaded. My fear is just, that a newer version comes up and breaks something in my program (DLL hell) and with a manifest it isn't easy to see from where something gets loaded and what version gets loaded.
  Looking in the app-local directory I would see files, but will this file be the one that gets loaded No. The manifest controls it and it gets complicated on a customers machine to see what is executed!
  
  
  

• Mark Olszowka

  A quick update - on my windows 2000 machine (god bless Virtual PC!):
  

  • Checking with 'dependency walker' shows an error finding the VC runtime on SMVSACore.dll - even if I place the manifest file directly in the same folder too
  • Installing the VS redistributable executable (from the Bootstrapper\Packages\... folder) fixes the issue in dependency walker, but the plugin fails to load (with a subtly different error message this time, being 'The system cannot find the file specified 0x80070002' versus the previous rather cryptic error of '<Unknown error> 0x80131534'

  Ta again,
  
  Matt
  -==-
  
  
  
  

• yysun

  Cheers Martyn - I'll give that a go, thanks for your reply.
  
  
  

• RamaswamySastri

  The product does include an EXE installer that installs everything to WinSxS. So you can use that if you prefer. You can find that here on your install:
  
  X:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
  
  However, if you want to install-applocal, you should make sure that your application has a manifest, and then copy the whole of this folder into your EXE directory:
  
  X:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
  
  and other folders if you use more than the CRT. Make sure you include the manifest.
  
  Martyn Lovell
  Development Lead
  Visual C++ Libraries
  http://blogs.msdn.com/martynl
  
  
  

• Dave Salzman

  That's right. You have to use a manifest. This is an essential deployment security issue. However, I think we can address your concerns.
  
  This shouldn't break any of your rules, because you can use manifests and ship completely app-local. There is no need to install anything in winsxs, or to use MSI.
  To be specific, there are files under the redist directory (DLLs and manifests) that you can install to your application's directory and have things work just as they worked without manifests. You remain in control.
  
  I don't understand your point about 'can't see what gets loaded and what not just looking at a customer's machine' Could you clarify what you are trying to find out
  
  In general, manifests are easier to diagnose (once you understand how to do it) because they do not depend on the setting of the PATH or other per-process state to understand how dependencies are bound, and when errors occur they write messages to the event log.
  
  Martyn Lovell
  Development Lead
  Visual C++ Libraries
  http://blogs.msdn.com/martynl

  
  

• tony_qy

  Martyn Lovell wrote:

  There are two ways to answer that question. The first is to say that our code contains enforcement logic that will generally force you to use a manifest, even when working app-local.

  
  
  So I can not link to the VC 8.0 CRT without using a manifest
  Even if I do not want a manifest
  I just tested some stuff with VC.NET 2005 but we aren't on production. But this is something that breaks some rules we ship our software, because we ship nearly everything app-local.
   
  The reason was simple: It gave us (you understand: us) the control. I don't like the manifest stuff very much, because I still can't see what gets loaded and what not just looking at a customers machine...
  Installing app-local was a method that was easy to control and its still something I prefer.
  
  

• ChrisParkinson

  Martyn Lovell wrote:

  However, if you want to install-applocal, you should make sure that your application has a manifest, and then copy the whole of this folder into your EXE directory: X:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT and other folders if you use more than the CRT. Make sure you include the manifest.

  
  
  Hi Martyn,
  
  Thanks again for your help - but this doesn't seem to be working.  Let me explain a bit more about the layout of my project.  It's a managed extension to Visual Studio called 'StyleManager.dll' which itself is dependant on our C++ layer 'SMVSACore.dll'.  Both DLLs are placed in our installation folder; and the managed dll is registered (via regasm).
  
  In order to get this working, I had to use the mt.exe program to attach the manifest into the DLL (SMVSACore.dll).  Without the manifest being attached to the DLL directly, Visual Studio was unable to load in StyleManager.dll (which faulted loading SMVSACore.dll because its dependencies couldn't be loaded.)
  
  Firstly, I'm a bit confused as to why I'd need to bind the manifest into the DLL; but I'm not too worred about this; a simple post-build step and it's all sorted.
  
  Moving to a Windows 2000 machine (and under VS2003 whereby the VC8 runtime isn't installed systemwide), the installer runs and installs StyleManager.dll, SMVSACore.dll, and the redistributable Microsoft.VC80.CRT folder into our installation location.  However, the plugin fails to initialise with what to all intents and purposes looks like it being unable to load SMVSACore.dll.  I know the plugin is loading OK as the messageboxes I've placed for debugging purposes are firing up - it's just when the plugin tries to call one of the exported methods from SMVSACore.dll that the 'file not found' exception is being thrown.
  
  This seems to be a fairly unusual setup not mentioned in any of the 'how to debug manifest.xml issues' help files, being a managed DLL loaded by a MS product itself loading another DLL which is dependant on SxS-controlled runtime DLLs (phew!).
  
  I'm utterly stumped at the moment - both with regards to how the manifest system works on pre-XP machines, and how to best deal with DLLs being loaded by DLLs.
  
  Any hints as to how to look into this gratefully received; this is beginning to bewilder me!  If I've been less than clear (and this /is/ a complex situation!) then please don't hesitate to ask any questions.
  
  Thanks in advance for any help,
  
  Matt
  -==-
  
  ps> I'm building all the managed DLLs using runtime 1.1 which allows the plugins to run inside both VS2003 and VS2005
  pps> when I say 'plugin' I mean 'Visual Studio Add-in' !
  
  
  

• Roose

  @Martyn:
  Just a question:
  When using the CRT of version 8.0 applocal, why should I use a manifest
  
  

• JuKu

  There are two ways to answer that question. The first is to say that our code contains enforcement logic that will generally force you to use a manifest, even when working app-local.
  
  But I think the deeper question you're likely asking is 'why did we do that' The key point about manifests is that they allow us to service DLLs in an emergency, whether they are installed app-local or centrally. I recently wrote a long blog post on this at http://blogs.msdn.com/martynl
  
  Martyn
  
  
• Redistribution of C runtime libraries without MSI installation