I see that v2.0: 75% there post mentions Autocad and there is an AutoCADApp.cs file, but I can't seem to find a reference for using Rubberduck outside of Office, under some random host application. There is this Adding a new Host Application to Rubberduck but that is already done for Autocad.
Using Rubberduck under Autocad requires building from source?
Or is there a procedure to use the already installed release package?
Disclaimer: I'm heavily involved with the Rubberduck project.
Likely you're simply missing the registry keys for AutoCAD's VBE to notice your ducky.
Rubberduck's installer searches for the bitness of your Microsoft Office install, and then registers itself using that bitness.
So if you have 32-bit Office and 32-bit CAD, you're all set. Ditto with 64-bit Office and 64-bit CAD. In your case you probably have 32-bit Office but 64-bit CAD, and so there's no registry key to tell a 64-bit VBE to load an add-in called Rubberduck.
You can run the PowerShell script you found in the project's wiki (it creates both 32 and 64 bit addin keys), or create the missing HKCU registry key manually, but then the add-in will be seen, but still won't load, because the COM interop stuff was registered under 32-bit nodes, and CAD will expect RD to be registered under 64-bit nodes. To register for 64-bit, you'll have to run (as administrator) a 64-bit regasm.exe command, as described in the "troubleshooting 'add-in could not be loaded'" section of the installer wiki:
Note: the bitness of your OS is irrelevant.
Bring up an administrative command prompt (cmd.exe), and execute one of the following commands:
32-bit host:
c:\windows\microsoft.net\framework\v4.0.30319\regasm.exe "(path to install folder)\rubberduck.dll" /codebase /tlb
64-bit host:
c:\windows\microsoft.net\framework64\v4.0.30319\regasm.exe "(path to install folder)\rubberduck.dll" /codebase /tlb
Note that these registration steps are required even if you build the addin yourself from the source code.
Related
I created 32-bit and 64-bit installation files respectively with Windows Installer. How can I create a unified installation file that can check the bits during installation, and merge these two into one to install automatically according to the bits?
Heath Stewart: Different Packages are Required for Different Processor Architectures. Here is an extract: "A common question is how to create a Windows Installer package that installs 32-bit binaries on 32-bit platforms, and both 32- and 64-bit binaries on 64-bit platforms. If you’re actually trying to install 64-bit binaries to appropriate directories and write to the 64-bit view of the registry, the short answer is that you can’t build a single package."
You should be able to use a setup.exe creation tool such as WiX's Burn or Advanced Installer or InstallShield (all can create setup.exe launchers). I am unsure of the built-in mechanisms they provide for this at the moment - I haven't looked at it for a while.
In any case you need a 32-bit setup.exe so that it can launch on both 32 and 64 bit systems and inside it you can keep your 64-bit setup along with the 32-bit one.
Rob Mensching's on the topic: How to deploy 64-bit and a 32-bit Windows Installer package as a single setup?.
Here is one of his blogs on Burn: https://robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn/ and here is the normal starting point in the WiX documentation for Burn.
Here is my attempt to show a basic, functional Burn package (many links - too many - towards the bottom).
Links:
Single MSI to install correct 32 or 64 bit c# application
https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/
VB.NET Winforms Program, .NET 4.0, compiled with VS2013. 100% managed code; no DLL that depend on a certain processor architecture.
I have two Visual Studio Installer projects, one for x86 and the other for x64.
The program "phones home" to find a new program; right now I detect the processor architecture to determine, if a new program exists, to download the 32-bit or 64 bit installers.
Detection code:
dim sArchitecture as String = ""
If Environment.Is64BitProcess Then
sArchitecture = "x64"
Else
sArchitecture = "x86"
End If
Problem scenario:
Customer has 64 bit machine but downloads 32 bit installer, which of course works properly. In fact, we advise customers who do not know their processor architecture to download the 32 bit installer.
32-bit installer program phones home and sends the x64 processor architecture it detects in the program. Download brings in 64-bit installer, which installs a second copy of the program into the customer's computer and confusion ensues.
What I need to figure out, if I use a Visual Studio installer project, with a TargetPlatform set to x86, is there some reliable way to detect this? Checking the install folder to see if it contains "Program Files (x86)" is insufficient; the customer may have installed the program to another location.
I would truly appreciate the Help!
Thanks
John.
Switch to the Release build and right-click your EXE project > Properties > Build tab. You have the Platform target set to AnyCPU and the Prefer 32-bit checkbox turned off.
Yes, very convenient that .NET program can automatically run in 32-bit and 64-bit mode. You don't need separate builds for the 32-bit and the 64-bit version, nice. Other than that your "detection code" no longer works reliably, the 32-bit installer still deploys a program that runs in 64-bit mode. The only way to discover what installer was used if it does not leave a bread crumb is to reverse-engineer it from the install directory. Yes, not very reliable. Leaving a bread crumb in the registry is otherwise very easy to do, installers are good at writing registry keys.
But just simplify your life, you just don't need a 64-bit specific installer at all. One gets the job done. That it is stored in the "wrong" directory just doesn't matter, you already know it works fine.
I have a windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
I have an ASP Classic application which references some VB6 COM OBJECTS. One of these VB6 COM OBJECTS reference another 3rd Party .Net DLL.
The 3rd party .Net DLL needs to be registered on a Windows Server 2008 R2 x64 machine.
I have found scripts to register the DLL in the GAC without GACUTIL using powershell (ref: http://weblogs.asp.net/adweigert/archive/2008/10/31/powershell-install-gac-gacutil-for-powershell.aspx)
Now I need to register the assembly. I have used both the GACUTIL and the REGASM on my local development machine (x86) without hitch. But when I try to get the DLL on the testing server I have problems.
First issue : NO GACUTIL
There is no GACUTIL on the server, which I got around using script noted above. I understand that it can be installed using the SDK but I do not want to "pollute" the environment.
Second issue : REGASM CANNOT FIND ASSEMBLY
The REGASM under the 32bit .Net Framework does not find the DLL. Error reported: "RegAsm : error RA0000 : Unable to locate input assembly 'C:\Windows\System32\xxxxx.dll' or one of its dependencies."
So I used the 64bit variant of RegAsm and that worked.
My concern though is that it is a false positive in that the ASP classic does not find the assembly as it is not registered by the 32bit RegAsm.
I run my application I get errors in my event log: "ActiveX component can't create object". Generally speaking that happens because it cannot find the object to create, which means that the DLL hosting the object is not registered correctly.
So what I am trying to do now is find out if there is an alternate method to REGASM using powershell that will register the assembly in the 32Bit scope.
Does anyone know if that is possible and what the script would be to get it right?
I found out that I was placing the .Net DLL in the incorrect folder on the test machine for registration.
On a windows 64Bit OS you have the System32 and the SysWOW64 folders. I placed my DLL in the System32 folder, where it should have been in the SysWOW64 folder.
The error I got from RegAsm ("RegAsm : error RA0000 : Unable to locate input assembly 'C:\Windows\System32\xxxxx.dll' or one of its dependencies.") should have made me click but I missed it.
Basically the 32 Bit RegAsm could not find my DLL but the 64 bit RegAsm could find my file and by registering the assembly with the 64 bit RegAsm I was putting the DLL into 64 bit scope. I needed it to be in 32 Bit scope.
I moved the DLL form System32 to SysWOW64 and the 32bit RegAsm found the DLL and registered it within the 32 Bit scope.
Now my VB6 COM object can find the .Net DLL and it works with out the error "ActiveX component can't create object".
With all that said, I have not found a library or function that will do the same job as RegAsm without actually using RegAsm.
If anyone finds this mythical beast please reply to this question. Thanks in advance.
Not sure, but your trouble seems to come from a side effect of UAC Virtualisation (this article can also help) which exists from Vista and is still valid here. An abstrat is that system parts of the file system and registry are now protected from user access, but to assume that old (32 bits) programs continue working the system make them believe they write on these parts, but in fact he redirect them to user's places.
Have a look in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node" in your registry.
A trouble I encounter recently is that my MSI was built with a 32 bits librarie, so invoking these libraries during installation on a 64 bits machine make UAC virtualisation install my registry keys in Wow6432Node. This Internet article helps me to solve the problem. I use Orca to replace Installutillib.dll from 32 to 64 bits.
I hope it helps
JP
I have installation solution that have installer project (not web installer but simple installer) that installs NT services, web service and web sites with help of additional two projects of dlls with my own code that performs my installation step. In user actions of installer project I call installer function of one of those projects, and this project calls to installer of second project: installer -> MiddleCaller -> InstallationCore.
All this developing on Windows 7 and work fine when I compile all in 32 bit.
The project must run on Windows 2008. Because of some reasons all must be in x64 bit.
For this purpose, in MiddleCaller and InstallationCore I click right button of mouse on project -> build -> targer x64. For to move installer project to 64 bit in properties of installer (when project is active) I check: Target platform: x64.
When I run installation on x86 I get error:
The installation package is not supported by this processor type"
And this is good, because now I know that my installation compiled in 64 bit, but when I run this on windows 2008 I get:
Error 1001. Exception occured while initializing the instance:
System.BadImageFormatException: could not load file or Assembly
'MiddleCaller, v...' or one of its dependencies. An attempt was
made to load a program with an incorrect format.
Any one has some idea what I need to do for run fine the installation on x64?
May be I still not moved the installer project to x64 bit, if yes, where I do this?
Thank you for ahead.
Found a quick tip on Microsoft's website that could be useful on troubleshooting setup and deployment projects:
64-bit managed custom actions throw a System.BadImageFormatException exception
If you add a 64-bit managed custom action to a Setup project, the Visual Studio build process embeds a 32-bit version of InstallUtilLib.dll into the MSI as InstallUtil. In turn, the 32-bit .NET Framework is loaded to run the 64-bit managed custom action and causes a BadImageFormatException exception.
For the workaround, replace the 32-bit InstallUtilLib.dll with the 64-bit version.
Open the resulting .msi in Orca from the Windows Installer SDK.
Select the Binary table.
Double click the cell [Binary Data] for the record InstallUtil.
Make sure "Read binary from filename" is selected and click the Browse button.
Browse to %WINDIR%\Microsoft.NET\Framework64\v2.0.50727.
Note
The Framework64 directory is only installed on 64-bit platforms and corresponds to the 64-bit processor type.
Select InstallUtilLib.dll.
Click the Open button.
Click the OK button.
There are some unclear things in this scenario. I understand that you are having difficulty running a 32-bit installer that calls on 64-bit assemblies. If this is correct, then what you are doing is not allowed. You cannot have 32-bit and 64-bit assemblies in the same process - that is illegal. If the 64-bit assemblies are being referenced by the installer directly, then the installer must also be 64-bit.
As clarification: I believe a 32-bit installer can install a 64-bit application, but it may only do so by copying the 64-bit files and not by actually making calls into the 64-bit files. The only way this is supported is if the 64-bit files are loaded into a different process and you use IPC to call into them, but even this is likely to be a bad solution.
In your case, I would encourage you to convert your installer into a 64-bit installer.
So, eventually, I compiled MiddleCaller and InstallationCore in AnyCpu mode, when all dll and executables that I need to install were compiled in x64 bit. All this I compiled on Windows 2008 x64 bit with x64 bit outer dependencies (like Oracle client).