In WiX, when I write a CustomAction in C#, the Visual Studio build first builds a small dll from my C# source code, then combines that small dll with SfxCA.dll, creating the actual file that gets added to the Binary table in the MSI.
Once the MSI has been built, if I extract the Binary object from the MSI and run ildasm on it, disassembly doesn't succeed.
What do I have to do to the Binary custom action object from the MSI so I can disassemble it back to C# source code?
You can open your *.CA.dll as cab in 7zip and extract all packaged files. Then use the disassembler of your choice to get the code.
Related
I have a file-translation library in the form of a Win32 EXE and a stub DLL that feeds parameters to it. I have written a lightweight (~500 lines) VB.net app that creates the file to be translated, then calls the DLL to launch the EXE. Unfortunately, this results in my EXE, their EXE, the DLL and another supporting file. I'd prefer to have a single file.
Following the basic idea here doesn't seem to help - I need to have all three files able to see each other, and it's not clear how to do this from those examples. I've also seen this, but again, this appears to be running an EXE that is "beside" the .net code, not embedded within it.
So, is there a way to run the EXE/DLL/supporting file "in situ"? Are the Assemblies ultimately a directory structure where I can run the EXE? And if so, how does one find/refer to these files?
How can you publish a WinForm that uses a .dll extension into one .exe file? I'm using VB.NET on Visual Studio 2013.
I have tried several methods such as using only the program .exe file from both the Debug and Release folder but these didn't work in isolation - a runtime error happened every time a command from the extension was used, as if it didn't exist.
My problem is packaging the entire program into one file. I don't want to have to use ClickOnce applications because you can't use a custom logo and so it kinda looks bad. I'll use it if there's no alternative.
I realised that the answer was to use the setup.exe file when publishing. Also, changing the logo of a ClickOnce program is possible.
I've got a .msi file produced by WiX which is working great, and now I want to wrap it in a bootstrapper. Previously I used setupbld, but as that is now deprecated I'm experimenting for the first time with burn from WiX 3.8.
However, every time I run burn from the command line nothing happens, regardless of parameters. I connected a debugger and got the following output if I run burn.exe with no parameters:
The program '[0x1380] burn.exe: Native' has exited with code -2147024883 (0x8007000d).
Does anybody know what is wrong here?
Note, I am literally running "C:\Program Files (x86)\WiX Toolset v3.8\bin\x86\burn.exe". I notice that burn.exe has an icon resembling an msi package (despite being an exe) so I'm not sure whether this is the installer for burn, or whether it is burn itself.
Tbh, I'm finding that although there is lots of documentation on writing the XML files needed by burn, there seems to be precious little on actually invoking it, and what to expect when one does.
Burn is the bootstrapper engine, not the builder. The error is ERROR_INVALID_DATA, which makes sense because burn.exe does have any data attached to it; The builder copies and modifies it to contain and/or point to containers for your bootstrapper's data.
To build a bootstrapper, you create a WiX document with a bundle element and then run candle.exe and light.exe on it.
Many people use a build system to run their tools and an IDE to manage their projects. WiX integrates with MSBuild and Visual Studio (non-free editions). There is a WiX Bootstrapper project template for Visual Studio provided, too. The SharpDevelop IDE has its own WiX templates (but currently not for the Bootstrapper.)
Note: All WiX projects are MSBuild projects so you can hand-write projects and/or build them with MSBuild instead of the IDE.
Is there any way in VB.NET to DllImport a dll file from the resources?
I really don't want to add the dll with the executable path.
You can embed a DLL into an executable:
Jeffrey Richter: Excerpt #2 from CLR via C#, Third Edition
Many applications consist of an EXE file that depends on many DLL
files. When deploying this application, all the files must be
deployed. However, there is a technique that you can use to deploy
just a single EXE file. First, identify all the DLL files that your
EXE file depends on that do not ship as part of the Microsoft .NET
Framework itself. Then add these DLLs to your Visual Studio project.
For each DLL file you add, display its properties and change its
“Build Action” to “Embedded Resource.” This causes the C# compiler to
embed the DLL file(s) into your EXE file, and you can deploy this one
EXE file.
At runtime, the CLR won’t be able to find the dependent DLL
assemblies, which is a problem. To fix this, when your application
initializes, register a callback method with the AppDomain’s
ResolveAssembly event.
Background to Question
I am currently in the process of trying to put together a means of distributing a new project I am working on which requires that a COM exposed .NET DLL be registered on the user's system and as I am new to WiX and making the move to it for this I am trying to keep things as simple as possible.
The Problem
The big issue with my DLL registration is that regasm sets the default value of the InProcServer32 key to "mscoree.dll", but my DLL can only seem to be instantiated when the full path to it is used, e.g. "C:\Windows\SysWow64\mscoree.dll"
Currently I have a custom action in my setup project (which I want to abandon to use WiX) which will call the SearchPath API to find the full path to mscoree.dll and overwrite the default value with the full path, so that the DLL can be instantiated without any issues.
Proposed Solution / Question
As I am new to WiX I have had the idea of preparing a .reg file that will contain all the necessary information to go into the CLSID tree and then having WiX execute that some how.
My question is:
Are there any inherent flaws by registering a DLL this way?
As the main reason I am trying to find work arounds here is the mscoree.dll issue, is there any native means of doing this in WiX?
Take a look at the WiX program called "Heat". This can "harvest" your DLL including registry information related to the RegAsm / COMVisible parts. You can then snip this code and work it into your wxs file.
You can also use Regasm /regfile and then manually transform that information into RegistryValue elements.
With regard to your path problem, use the SystemFolder property.
[SystemFolder]mscoree.dll
If you mark your install as 32bit (x86) this will automatically resolve to the SysWow64 folder when run on a 64bit OS and the System32 folder when run on a 32bit OS.