runtime redistributable?

runtime redistributable?

• Bassel Samir Banbouk

  Look here:
  Program Files\Common Files\Merge Modules
  
  If you want to use a application local installation for those files, you will find the files in your WinSxS directory.
  
  Read this and surrounding topics
  http://msdn2.microsoft.com/en-us/library/ms235290.aspx
  
  

• www.etramway.com

  Thanks, I had found that too, but shouldn't there be one for the (non-beta) final product How are people supposed to distribute their apps if they haven't got the redistributables..
  

• Blanca Flores

  I could only find the Beta 2 versions on MS downloads: http://www.microsoft.com/downloads/details.aspx FamilyID=25ae0cd6-783b-4968-a841-38a2743307d9&DisplayLang=en
  
  

• Dan.B

  I have the same problem: I want to redistribute applications, but I want them to work on Windows 2000 as well (legacy) and 2003 server (I build on XP).
  
  It seems that the merge modules can be used only to produce an installer that will do a side-by-side install using the WinSxS folder.
  
  I would be more interested by a private side-by-side kind of thing (and I don't want to force people to have administrator rights to run/install my app).
  
  Can somebody point me to a place where I can find information on doing this with the express edition
  
  thanks
  
  Nicolas
  

  
  

• kids_pro

  I can smell some irony here: as I just posted my "success" story, I found out that some of the sub components in my app don't work anymore.
  
  I found that the reason is that dlls are searched in the order:
  
  WinSxS then
  next to the executable
  
  and that is it.
  
  but in my case, the dlls are in the current working directory, not the folder with the binary. The reason behind this is that my install looks like that
  
  Install Folder
     main.exe
     runtime dlls + manifest files
     subcomponents
          component1.exe
          component2.exe
          ...
  
  main.exe launches different components by invoking a CreateProcess from "Install Folder" of subcomponents\componentX.exe
  
  note: if I copy my runtime dlls and manifest file in the subfolder, everything is fine, but that is really ugly.
  
  I tried to set the PATH variable to the install folder, but manifest files are not searched like that.
  
  I also tried to put a copy of the manifest file in the subcomponents folder, and reference the dlls one level up, but that didn't work either (not pretty, but I figured at least I was not duplicating the dlls).
  
  It seems that I am hitting a dead end here...
  

  
  

• Mario Lucin

  Ah but this doesn't work in the final (RTM) version of VS 2005:
  
  the problem being that applications compiled with this version have a RT_MANIFEST with a version of 8.0.50608.0
  but the supplied runtime is version 8.0.50727.42
  
  The use of the correct runtime is done via a policy file (that says bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0" newVersion="8.0.50727.42")
  
  If I manually change the version embed in the resources of the application to be 8.0.50727.42, then I can do an install just like the explanations provided on nikolad's blog.
  
  the problem is that this is not the correct way to do things because I don't want to edit the manifest by hand everytime I compile an app.
  
  So instead, I tried to see if I can put a policy information next to the app, but it doesn't work.
  
  Then I tried to tweak the manifest file of the runtime to add the "bindingRedirect" item, but couldn't make it work.
  I found there http://msdn.microsoft.com/library/default.asp url=/library/en-us/sbscs/setup/manifest_file_schema.asp that the bindingRedirect is allowed in a manifest file, but I didn't find the way to really use it.
  I tried to do add something like that (attributes and values ommited):
  <description>
  <dependentAssembly>
  <assemblyIdentity>
  </assemblyIdentity>
  <bindingRedirect>
  </dependentAssembly>
  </description>
  
  So, any idea
  

  
  

• bhoffmancsi

  You can install application local. Read this
  http://blogs.msdn.com/nikolad/archive/2005/03/18/398720.aspx
  
  

• donall

  fantastic, thanks.
  

• pehaada

  Yes you are right!
  I just revied the SDK docs about private assemblies:
  http://msdn.microsoft.com/library/default.asp url=/library/en-us/sbscs/setup/private_assemblies.asp
  
  There are more locations but the solution you are searching for is not available.
  
  Take care! If you place a CRT DLL in more than one directories and you use all those applications at the same time. the CRT DLLs are not shared if the CRT DLLs reside in different directories. So if you have 10 own inproc servers in 10 different directories with its own 10 CRT DLLs, than all 10 CRTs will be loaded.
  
  

• Shailendra18

  I found a workaround to be able to run my application, but I really don't like it:
  
  by just putting the old version 8.0.50608.0 in the runtime's manifest file (even though the dlls are the new version), the app can load properly.
  
  My thought is that I think that this should have failed: there doesn't seem to be a check that the version described in the manifest file is the same than the one from the dll.
  
  On the other hand, that solves my problem, so as long as there is no way to write a local policy file (the same way there can be local manifest files), I am happy with that. By local, I mean, in the current working directory.
  

  
  
• runtime redistributable?