Last active
August 29, 2015 14:07
-
-
Save coridrew/6bee6cceed604e383829 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Overview: | |
1. Client built logging framework | |
2. Framework uses WMI & "installer(?)" needs to create custom categories ("LogEvent" class inherits from System.Management.Instrumentation.BaseEvent), so must run under full trust. | |
3. He wants to roll it out to 38 apps/sites, all still on .NET Framework 3.5. Not sure about how many servers host it, but see #4. | |
4. Overheard question from yesterday was, "I'm trying to build an msi to install on all of the machines, but I can't figure out how to make it install into x64 if machine can handle it, and x86 if machine is not x64" | |
----- | |
My questions: | |
1. Is an msi necessary, or can this just be done with a powershell script in a Chocolatey package? | |
2. Is "detecting system & installing in different locations" a thing? | |
At Vermont Code Camp, I heard this sentence, "People don't understand that you should only use x64 if you have really functional code, like mathematical computations, that will really benefit from x64. Otherwise it's too expensive." | |
I think that might have been intended for .net project deployments, but I have not done enough to fully grok when you should & should not, what the differences are with the system resources, registry, etc., and would like to understand better. | |
BTW, 32-bit MSIs can install 64-bit systems. They install into Program Files (x86)
and use the 32-on-64 registry keys.
64-bit MSIs cannot install on 32-bit systems. They install into Program Files
and use the main registry keys.
BTW, if this is a pure .NET app, why not just target "Any CPU"? If you do that, your installer might be a "32-bit" MSI, but the assemblies can run on the 64-bit framework.
Assuming this is a COM DLL, not a .NET DLL, then to register it you need to:
C:\Windows\SysWOW64\regsvr32.exe
C:\Windows\System32\regsvr32.exe
The first version (WoW64) will only exist on a 64 bit machine, and only is needed to register on a 64 bit machine accessing a 32bit COM DLL
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you want to use MSI for this, you'll need to roll separate MSIs for 32-bit and 64-bit systems. If you don't have some automated process to deploy the right MSI, you'll need to provide a little front-end app that decides which MSI to install. This app is termed a "bootstrapper", and its traditional name is
Setup.exe
.I'm not sure what tooling your client is using to build their MSIs, but I do know that the WiX toolset has facilities to make the bootstrapper for you. See here: http://wixtoolset.org/documentation/manual/v3/bundle/
I don't know if Chocolatey is appropriate.