I tried this question on the InstallShield forum and it hasn't gotten any love. My company has an InstallScript project (non-MSI), and we need to run RegAsm /codebase on one of our DLLs. I found some tutorials online for doing this, but they don't seem to apply to our project type. That is, the options I need simply do not exist in the UI. That includes both suggestions here (https://www.iwasdot.com/installshield-execute-a-batch-script/) as well as anything involving custom actions (as I interpret from the docs that custom actions do not apply to InstallScript projects). How can I accomplish this with InstallScript? I am using InstallShield 2013 and I know extremely little about it.
I haven't used InstallScript projects in almost 20 years but I imaging you'd write an InstallScript function to call LaunchAppAndWait to invoke Regasm.
If I recall correctly, InstallScript project types have events like After File Copy that you can use to put the code into.
Christopher Painter is correct. I came to the same conclusion and was able to get this to work. If it helps anyone in the future, here's more specifically what I did:
I went to the "Behavior and Logic" folder of the "Installation Designer" tab and selected "InstallScript". Then on the right-hand pane I selected the feature my DLL is associated with and then selected the "Installed" event handler. The following script registered my DLL for COM interop:
LaunchApplication("C:/Windows/Microsoft.NET/Framework/v4.0.30319/RegAsm.exe",
"../path/to/my.dll /codebase", "",
SW_HIDE, 0, LAAW_OPTION_NOWAIT);
And then I did something similar for the "Uninstalled" event handler:
LaunchApplication("C:/Windows/Microsoft.NET/Framework/v4.0.30319/RegAsm.exe",
"/unregister ../path/to/my.dll", "",
SW_HIDE, 0, LAAW_OPTION_NOWAIT);
Related
I have msi setup that was created in installshield and I am executing the DTF custom action dll as a commit custom action. If I insert MessageBox.Show into the custom action, I can see that there is a temporary folder inside [PROGRAMFILESDIR] called "CustomActionProject.CA.dll-" and there is copied CustomActionProject.CA.dll with all its references.
Is there any way to tell the technology not to create this temp folder and extract+execute the CustomActionProject.CA.dll in the same folder where is .CA.dll located?
Edit:
I found out that I can not include the references in .CA.dll by configuring wix.ca.targets. Which prevents .CA.dll to contain 20MB of dlls in my case.
Now I would like to make sure that CustomActionProject.dll will be able to see the references that are installed with the product.
The files are:
<ProgramFilesFolder>
<MyApplicationFolder>
CustomActionProject.CA.dll
... About 30 dlls installed with the application that CustomActionProject.dll needs to call
<Place I Would Like to See CustomActionProject.dll extracted>
DTF automatically extracts it's files to a temp folder for execution and then cleans up on disposal. This is very good in that it eliminates certain race conditions. You can still author those files into your installer if you like. For example, at a previous company, our installer used several DLL's for license checking during the install and installed them for use by the application at runtime.
BTW, make sure you've seen this:
WiX DTF Behavior Alert
Your custom action was programmed in a managed .Net language (probably C# or VB.Net). As msi files may only contain dll custom actions comprised of native code the DTF tools, specifically the tool makesfxca.exe, packs / wraps the managed dll together with helper code resulting in a self extracting, native code dll. Following WIX´s naming convention the native custom action dll contains an .CA infix.
In order for this (i.e. having custom actions written in languages producing managed code) to work, self extraction has to take place. So the short answer to your question is "No".
For my project, I need to generate CAD drawing (almost a blueprint of a tank) through my VB.NET application. The app takes in some user input & based on this, it generates the geometry of the tank.
I am using Microsoft Visual Studio Professional 2012 & coding in the VB.NET language.
I have browsed through a lot of AutoCAD documentation but could not find exactly how & where are the modules hidden, for me to add them into my code.
I stumbled accross one particular document
which is where I found how to add the relevant files as reference to my VB solution. However, after adding some particular files I could then do Imports AutoCAD, but all the docs show that I must use Autodesk.AutoCAD. On inspection of the available modules/methods of the Imports AutoCAD I can see that it isn't complete as needed for the application development.
Can somebody please guide me as to how could I find or go about adding correct reference files to my VS solution to get full functionality from the AutoCAD modules? Thanks!
I posted this quite some time ago. It contains the information that you need
How to close a file in Autocad using C# keeping acad.exe running?
You can also download any of the AutoCAD .NET API's from here:
http://usa.autodesk.com/adsk/servlet/index?id=1911627&siteID=123112
Just in case someone else need the help.
Download the appropriate AutoCAD .NET API using the aforementioned link.
Put them in a location of your choosing.
general:
on the appropriate project in your visual studio's solution, right click -> Add Reference.
select Browse on left, click the browse button and go to the path where you saved the ObjectARX download.
Inprocess:
Navigate to the inc directory and
select the AcDbMgd.dll and AcMgd.dll then click add.
For these make sure to set the copy local property to false.
Interop:
Navigate to the appropriate directory: inc-win32 or inc-x64 depending on your processor.
select the Autodesk.AutoCAD.Interop.Common.dll and Autodesk.AutoCAD.Interop.dll then click add.
and unless you have an interest in the AutoCAD interface don't worry about the AcCui.dll
Hope this helps some one out :)
So, looking up more & more documentation led me to stumble across this
I found the dlls by simple file search for respective dlls metioned below in my local AutoCAD 2014 installation folder (C:\Program Files\Autodesk\AutoCAD 2014)
As per the documentation, following dlls are important ones -
AcCui.dll
acdbmgd.dll
acmgd.dll
Autodesk.AutoCAD.Interop.dll
Autodesk.AutoCAD.Interop.Common.dll
The credit for the last 2 dlls goes to Trae Moore.
How to add references to the dlls was mentioned in the documentation link.
I'm trying to interact with a .dll which will allow me to receive information from a variety of devices (Eye Gaze to be specific). The .dll is called ETUDriver and can be found at http://www.sis.uta.fi/~csolsp/projects.php however it does not come with an accompanying .h file.
I am struggling to actually load, interact and invoke functions from the .dll. A manual is supplied but it is of no help whatsoever with regards to actually setting up the code to start it off. There are three accompanying example apps (with source code) but only two of these work and one of which is in C# so is not helpful. The one that works however loads up the .dll via MFC and this is not a viable option with my code (which is intended to be used with many other projects and as such can't enforce MFC or any other libraries that are not as standard to projects).
Essentially, within the .dll is a series of classes which I need to create within my code and invoke the relevant functions of that class.
I've tried to use HRESULT hr = CoInitialize(NULL);
hr = CoCreateInstance(__uuidof(ETUDSink), NULL, CLSCTX_INPROC, __uuidof(IETUDSink), (LPVOID*)&pETUDSink);
if(pETUDSink)
{
pETUDSink->Start();
} however it always returns an error saying that the class is not registered. I can't use MFC to call the relevant .rgs file and am completely stuck on how to get this to work otherwise.
Is there a given format to doing this that I am unaware of and has anyone had experience in using the ETUDriver (or is able to get it working in C++ without use of MFC)?
Thank you for any help you can provide on this subject :)
I am not familiar with the specific DLL in question, but it sounds like you did not register the DLL on the target machine. You can do this by running regsvr32.exe or by calling the DLL's exported DllRegisterServer function or by using side-by-side assemblies. You need to do register the DLL on each machine that needs to leverage the COM functionality within it, so when you distribute your application, make sure that your installer registers the DLL if you go the regsvr32.exe route.
You can use the #import directive in Microsoft Visual C++ to load the information contained within the DLL without using a header file or rewriting it yourself based on documentation.
I'm trying to write a IL Weaver with Mono.Cecil, and for it to remain debugable in VS2010, I need the PdbReaderProvider class, or some similar implementation of ISymbolProvider. I've downloaded the latest Mono dlls from http://mono.ximian.com/daily/, but in the zip there is no Mono.Cecil.Pdb.dll. I've downloaded the source code from https://github.com/jbevain/cecil/tree/master/Mono.Cecil but I can't seem to be able to get that particular project compile under .net 4.
Could somebody help me out and point to a compiled working .net dll of Mono.Cecil.Pdb, preferably with a working PdbReaderProvider inside?
Indeed, you need to get the source from Cecil's github repository. Then you just have to open Mono.Cecil.sln inside VS 2010, select the solution configuration net_4_0_Debug (or net_4_0_Release) and build the solution. The solution is self contained so you don't need anything else.
You'll get both Mono.Cecil.dll and Mono.Cecil.Pdb.dll inside bin/net_4_0_Debug (or bin/net_4_0_Release).
Alternatively, get the NuGet package which includes all Cecil assemblies. If you're on the MS stack, of course.
I have been trying to load a OCX file into one of my VB6 projects for most of the day today. I've tried checking the COM registration in the registry the best that I know how, and have attempted several times using REGSVR32 on the file to no avail. All I keep getting from VB6 when I try to load the component (Under Project --> Components) is 'FilePath\FileName.ocx' could not be loaded. Has anyone else seen this before, and if so, any ideas how to fix it?
Just a couple of tips to help isolate the problem....
Look at the control with OleView
Examine the name: if it is one of the reserved words such as 'Menu', vb6 will fail to load it. (Although vb6 will happily let you create (and use) one with a bad name until it is saved and reloaded)
Examine the interface: does it describe the functionality? You may have a damaged or unlicensed ocx.
Attempt to load it with the ActiveX Control Test Container...
If you can, the problem is with VB6 and not the ocx.
This it may be a dependency issue -- some other component needed by the OCX is not present. Dependency Walker will find any static dependencies.
We fixed similar error recently. In our case the error was in the Visual Basic project (.vbp) file. Project file had been edited outside standardized build machine and contained references to OCX components - including workstation specific paths & versions of the components.
You can either edit the the project file in text editor or get a working version from version control.
Un-registering and registering again worked for me too.
Please note that you need to register this component using this syntax:
regsvr32 /i:design olch2x8.ocx
When you say you have used "REGSVR32 on the file to no avail" do you mean that you get a file name succeeded message, or an error message? If registering the file succeeds CMB is likely right about the ocx being unlicensed.
Licensing aside, there are a couple of other trip points with vb6. Especially if the OCX was developed in VB6.
If so, the 'officially' system registered version may conflict with the specific ocx you're using. In other words, both of them might have the same proper name (or classid) but the one you're attempting to use may not implement all the functionality described in the system registered one (i.e. you have a less evolved version). This arises when the author desires to maintain binary compatibility while enhancing the functionality of a control. As long as the public interfaces remain compatible, vb will not recalculate the classid.
You can fix this by forcibly unregistering the specific control (actually unregister all instances of the control). (regsvr32 /u control.ocx ) Then re-register the one you intend to use. Be certain that no running instance of VB6 exists when you do this or the results might not work. (Check your task list)
Hope that helps...
The control may be reliant on another DLL or OCX that may be missing or not registered and this could manifest itself as VB reporting that the control you're trying to use is missing. However, I'm not sure how you would identify the dependencies. As far as I know, dependency walker identifies static dependencies; I'm not sure if it can identify COM dependencies.
Un register the Ocx
re register the ocx
then loaded the project again in VB6, it worked for me.
Thanks everyone