Ok, I got my archive working on the new server. Most things work, but...
...I get a vgreat crash on checkin if the file was changed. DW20.exe starts running.
Error I do get is:
The description for Event ID ( 5000 ) in Source ( .NET Runtime 2.0 Error Reporting ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: clr20r3, w3wp.exe, 6.0.3790.1830, 42435e74, mscorlib, 2.0.0.0, 4333c8f6, 11c6, 18, system.io.filenotfoundexception, NIL.
Anyone an idea what that is?
Note that the following dll's are not in the /bin directory:
CustomActionExe.exe
CustomActions.dll
VaultPluginLib.dll
SGDiff.dll
mmssexlib.dll
Reason: if some of those are present, the web app does not start. Can it be we have some native win32 code in there? I am running that on a Win64 system.
Get, checkin without change and all that are working flawless.
Crash on checkin
Moderator: SourceGear
We have not fully tested Vault on 64-bit operating systems. We do know that the registry is different on 64-bit machines, and Vault is not yet written to accomodate that. For that reason, Vault is not supported on 64-bit systems. We do plan full support in Vault 3.5, due out in a few months.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
No way to get it working? YOu mean I uploaded my archive to a web hoster to get it rid of my personal systems for two days, just to find out that current versions of the OS are not supported, although your technology is platform independant.
Now THAT is - well, propably as nice as dumping dll's that the installer uses into the /bin directory.
Ok, what now? No way to get it working? What do you do on the dreaded registry anyway?
Note that your documentation does not say you do only support 32 bit versions. Damn. I spent two days handling that including manual installation of the whole thing in a hosting environment.
Now THAT is - well, propably as nice as dumping dll's that the installer uses into the /bin directory.
Ok, what now? No way to get it working? What do you do on the dreaded registry anyway?
Note that your documentation does not say you do only support 32 bit versions. Damn. I spent two days handling that including manual installation of the whole thing in a hosting environment.
The Vault Installer writes to the registry and various values used by Vault are stored in the registry.
One user found that after installation certain Vault information was located in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SourceGear\VaultServer rather than the expected location:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceGear\Vault Server
The 64-bit Windows OS uses the Wow6432Node key to present a separate view of HKEY_LOCAL_MACHINE\SOFTWARE for 32-bit applications that run on a 64-bit version of Windows. When a 32-bit application queries a value under the HKEY_LOCAL_MACHINE\SOFTWARE\<company>\<product> subkey, the application reads from the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<company>\<product> subkey. A "registry reflector" copies certain values between the 32-bit and 64-bit registry views (e.g., mainly for COM registration) and resolves any conflicts using a last-writer-wins approach.
We'll need to make some changes to the Vault installer to accomodate this difference in the registry for 64-bit windows.
One user found that after installation certain Vault information was located in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SourceGear\VaultServer rather than the expected location:
HKEY_LOCAL_MACHINE\SOFTWARE\SourceGear\Vault Server
The 64-bit Windows OS uses the Wow6432Node key to present a separate view of HKEY_LOCAL_MACHINE\SOFTWARE for 32-bit applications that run on a 64-bit version of Windows. When a 32-bit application queries a value under the HKEY_LOCAL_MACHINE\SOFTWARE\<company>\<product> subkey, the application reads from the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<company>\<product> subkey. A "registry reflector" copies certain values between the 32-bit and 64-bit registry views (e.g., mainly for COM registration) and resolves any conflicts using a last-writer-wins approach.
We'll need to make some changes to the Vault installer to accomodate this difference in the registry for 64-bit windows.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
Well, I do not even try to run the installer on the server. Not allowed toö.
I follow the instructions given in http://orangetoad.com/?p=5 to get an installation running only for the server. That should actually work - without any registry key.
Btw., you have a lot more problems with your installer. Such as the §$()% idea to have a CustomActions.dll (and accompanying CustomActionExe.exe) that are pretty obviously MSI installer custom actions and that someone on your staff decided to dump into the website's /bin directory. These blow on 64 bit systems (being 32 bit dll's trying to be accessed from 64 bit ASP.NET during compile phase). The really crazy thing is that they do not belong there at all, IIRC, because they are only thre for the installer.
Frankly, you list Window 2003 X64 as supported operating system in your documentation. Your system requirements say "Windows 2000 or above", no word about "32 bit only". They say "Vault 3.1 is compatible with version 1.1 or version 2.0 of the .NET Framework". No word about "32 bit only".
It takes maybe a day to fix the installer. Or to come up with proper installation instructions to get the website operational manually (which really really really I Would prefer - I never liked the idea of having to run an INSTALLER just to get a website set up). That is mostly because it makes putting the whole thing onto a shared server so extremely hard.
I follow the instructions given in http://orangetoad.com/?p=5 to get an installation running only for the server. That should actually work - without any registry key.
Btw., you have a lot more problems with your installer. Such as the §$()% idea to have a CustomActions.dll (and accompanying CustomActionExe.exe) that are pretty obviously MSI installer custom actions and that someone on your staff decided to dump into the website's /bin directory. These blow on 64 bit systems (being 32 bit dll's trying to be accessed from 64 bit ASP.NET during compile phase). The really crazy thing is that they do not belong there at all, IIRC, because they are only thre for the installer.
Frankly, you list Window 2003 X64 as supported operating system in your documentation. Your system requirements say "Windows 2000 or above", no word about "32 bit only". They say "Vault 3.1 is compatible with version 1.1 or version 2.0 of the .NET Framework". No word about "32 bit only".
It takes maybe a day to fix the installer. Or to come up with proper installation instructions to get the website operational manually (which really really really I Would prefer - I never liked the idea of having to run an INSTALLER just to get a website set up). That is mostly because it makes putting the whole thing onto a shared server so extremely hard.
