Stefan Küng wrote:
> Arne Moor wrote:
>> Hi together,
>>
>> I tried to install the nightly build 5085 on a laptop of the company
>> I'm working for, to see what 1.3 will bring, since I'm in the process
>> of implementing 1.26 there.
>>
>> Setup started, I confirmed all the settings, the setup started copying
>> files, but then at the end of the setup I got the error message shown
>> in the attachment: "1: ALLUSERS property not set to 1 - this MSM
>> cannot be used for a per-user or fallback-to-peruser install".
>>
>> The useraccount I tried to run the setup is not an administrator
>> account, it is a normal user account with some additional rights
>> assigned.
>>
>> Does anyone has an idea how to solve this?
>
> I think there's just no way to solve this. You see, with VS.NET2005, MS
> ships newer versions of MFC and CRT (versions 8.0). Before, those dll's
> were considered project based, i.e. you were not allowed to install them
> in the system folders (c:\windows and below) but you had to install them
> in your project folder.
> Now, with the new versions, MS decided that these must be installed in
> the system folder as side-by-side assemblies. The merge modules they
> provide for this take care of the installation to make sure everybody
> installs them correctly. And since they are installed in the system
> folder, you must have Admin priviledges for installing them.
>
> Stefan
>
Hi,
with 1.3.1 it doesn't let you start the setup, thanks that you changed
the setup to check for admin privileges. But there is a solution to
deploy without admin-rights!
As in our company by policy per machine installations are only allowed
by engineering, for which I guess it will take some additional months to
deploy the Vs2005 runtime, i searched a little bit....
What I found is interesting in that it's not a MS must to install them
as side-by-side assemblies. In the MSDN library at
http://msdn2.microsoft.com/en-us/library/ms235317(en-US,VS.80).aspx
under "Procedures for deploying Visual C++ library DLLs as private
assemblies" they describe that it's Ok to deploy the CRT and MFC as
private assemblies.
As MS describes at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/assembly_searching_sequence.asp
it's even no conflict or problem with updates, since as soon as the CRT
and MFC are deployed as side by side assemblies into %windir%\WinSxS
those are allways used over the private ones.
A proposal to make all the user (inside biger companies) happy:
- Leave the current check for MFC inside WinSxS as it is.
- If not installed copy the following from VS2005 to TortoiseSVN\bin:
\VC\redist\x86\Microsoft.VC80.CRT
\VC\redist\x86\Microsoft.VC80.MFC
\VC\redist\x86\Microsoft.VC80.MFCLOC
- remove the MSMs from the setup.
- Let also none-admins start the setup.
I tried this today, installed TSVN 1.3.1, removed temporary all MFC &
CRT stuff and copied those three folders into TortoiseSVN\bin.
Dependency Walker showed that they where successful used. Afterwards I
re-enabled the original WinSxS stuff and after a reboot those files
where used instead of the private assemblies.
Any comments?
Arne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 14 23:13:33 2006