I created a cab file that contains my activex using CABARC.exe. I also created an .inf file. My inf file looks like this:
[version]
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
MySetup.exe=MySetup.exe
[MySetup.exe]
file-win32-x86=thiscab
clsid={49892510-B520-4b35-8ADF-57084DD2F717}
My html looks like this:
<object name="secondobj" style='display:none' id='TestActivex'
classid='CLSID:49892510-B520-4b35-8ADF-57084DD2F717'
codebase='http://myurl/MySetup.cab#version=1,0,0,0'></object>
I created the CABARC using the following commmand:
C:\tools\Cab\BIN>CABARC.EXE N MySetup.cab MySetup.msi setup.inf
I also added http://myurl to the trusted sites. Now the first time I opened the html page in IE, I saw a yellow bar, which I accepted. However it never installed the activex control. I dont see the installation in my program files nor can I see anything in the event logs or in the temporary download folder or in the "manage add-ons". Now everytime I open the webpage in IE, I do not see the yellow bar anymore.
Can anybody help me out here please?
It seems to me you are packing msi installer instead of ActiveX control.
When you extract your control from MSI installer and pack it into CAB, don’t forget to add it’s version to the INF file.
Hope it helps…
Packaging ActiveX Controls
VS 2008 provides an excellent CAB Project. You can find it under Other project types / Setup and deployment / CAB project.
For simple CAB projects you just need to add your component project output.
If you need also to sign your CAB you must edit project properties adding the post build signtool.exe command, but once you are able to sign the component via cmd line you just need to copy the command line to post build event.
Using $(ProjectDir) macro may help to generalize the process for automated build.
It looks like my .inf was off. Here is what worked for me:
[version]
Signature="$CHICAGO$"
AdvancedINF=2.0
[Setup Hooks]
hook1=hook1
[hook1]
run=msiexec.exe /i "%EXTRACT_DIR%\MySetup.msi" /qn
To make the cab:
CABARC.EXE N MyActiveX.cab MySetup.msi setup.inf
Related
Hope you can help me. I am looking forward to programming my first MS Access AddIn with Visual Studio 2015 (a Ribbon-Bar as VSTO), but not having started I have to stop already. Visual Studio provides templates for almost every office product, but MS Access. I heard it is possible to "change" for example the Excel VSTO-Template so it can be used to develop an MS Access Ribbon.
Does anyone know a good instruction how to handle this? How are you developing VSTO for MS Access?
Thanks for your help
There exists a tutorial for this. I haven't tried it, don't know if it works, but it sounds promising.
Here are the juicy bits.
To start building an Access add-in, I could create a Word (or InfoPath, PowerPoint, Project or Visio) add-in (Excel or Outlook would also work, but they have additional redundant host-specific code).
Then, I'll add a reference to the Microsoft Access Object Library, on the COM tab (this also pulls in references to ADODB and DAO). It also pulls in Microsoft.Office.Core.dll, which duplicates the Office.dll already referenced by default - so I'll delete one of these two duplicates.
In Solution Explorer, I can select the project and click the "show all files" button. This makes it easier to open the ThisAddIn.Designer.cs file – here I can change the declaration and initialization of the Application field from M.O.I.Word.Application to M.O.I.Access.Application. Note that this step changes a file that is auto-generated: the file is not normally re-generated, but can be if I corrupt the project (the point being that my manual changes will be lost if the file is re-generated):
//internal Microsoft.Office.Interop.Word.Application Application;
internal Microsoft.Office.Interop.Access.Application Application;
//this.Application = this.GetHostItem<Microsoft.Office.Interop.Word.Application>(typeof(Microsoft.Office.Interop.Word.Application), "Application");
this.Application = this.GetHostItem<Microsoft.Office.Interop.Access.Application>(typeof(Microsoft.Office.Interop.Access.Application), "Application");
That's all the code changes. Now for the project changes. There are two ways to do these changes – through the IDE in a way that overrides or counters the default settings; or by manually editing the .csproj file directly, to replace the default settings. Let's look at both approaches: first through the IDE, then manually.
First, I'll change the Project Properties | Debug | Start action, to "Start external program", and specify the path to Access, for example:
C:\Program Files (x86)\Microsoft Office\Office12\MSACCESS.EXE
Then, I'll create a .reg file with the same name as my add-in solution, and put it in the solution folder. This reg file is used to register the add-in for Access (and unregister it for Word). The example reg file listed below is simply a dump of what the standard VSTO build task does for each add-in type, with an additional line. The additional line (the first reg entry below) simply removes the entry that the build task puts in for Word. The remaining entries are identical for Word and Access, with the only changing being to replace "Word" with "Access":
Windows Registry Editor Version 5.00
[-HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\MyAddIn]
[HKEY_CURRENT_USER\Software\Microsoft\Office\Access\Addins\MyAddIn]
"Description"="MyAddIn"
"FriendlyName"="MyAddIn"
"LoadBehavior"=dword:00000003
"Manifest"="C:\\Temp\\MyAddIn\\bin\\Debug\\MyAddIn.vsto|vstolocal"
In Project Properties | Build Events, I add a Post-build event commandline to merge the .reg file into the registry:
regedit /s "$(SolutionDir)$(SolutionName).reg"
That's it. I can now press F5 to build the solution: this will register the add-in for Access, and run Access for debugging with the add-in loaded.
Note that instead of setting the Debug property to an external program (step 4 above), I could modify the .csproj file directly, to set the from Word to Access. For example, change this:
<ProjectProperties HostName="Word"
HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
ApplicationType="Word" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Word\InstallRoot\Path#WINWORD.EXE"
AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
… to this:
<ProjectProperties HostName="Access"
HostPackage="{D2B20FF5-A6E5-47E1-90E8-463C6860CB05}" OfficeVersion="12.0" VstxVersion="3.0"
ApplicationType="Access" Language="cs" TemplatesPath="" DebugInfoExeName="#Software\Microsoft\Office\12.0\Access\InstallRoot\Path#MSACCESS.EXE"
AddItemTemplatesGuid="{147FB6A7-F239-4523-AE65-B6A4E49B361F}" />
Note that changing the value, as show above, changes the icons used in the Solution Explorer .
I could also change the element's Name value to change the name of the parent node for the ThisAddIn.cs in the Solution Explorer. Change this:
<Host Name="Word" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
<HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>
… to this:
<Host Name="Access" GeneratedCodeNamespace="MyAddIn" IconIndex="0">
<HostItem Name="ThisAddIn" Code="ThisAddIn.cs" CanonicalName="AddIn" CanActivate="false" IconIndex="1" Blueprint="ThisAddIn.Designer.xml" GeneratedCode="ThisAddIn.Designer.cs" />
</Host>
Also, registration is determined by the element value. So, instead of setting up a .reg file as a post-build task (steps 5-6 above), I could edit the .csproj directly to change this:
<OfficeApplication>Word</OfficeApplication>
…to this:
<OfficeApplication>Access</OfficeApplication>
I'm trying to create a "Configuration.ini" file to automate a future SQL Server Express 2014 installation. I have found several posts from all over the 'Net that tell me to go thru the installation as normal, choose all my settings, and before it's ready to install, the "Ready to Install" text on the left-hand corner of the screen will be bold and there will be a TextBox on the bottom with a path to the configuration file. As it turns out, neither one of these are showing up on the screen, and the Setup is not creating a Configuration.ini file. Why is it not creating an .ini file for me?
I found a post on codeproject.com that answered my question (http://www.codeproject.com/Questions/713204/SQL-Server-How-to-generate-a-configuration-fi) . When launching the setup.exe file for SQL Server 2014 Express, you need to pass in the following parameters when running the setup.exe in order for it to create a configuration.ini file:
Setup.exe /ACTION=INSTALL /UIMODE=Normal
When you pass in these parameters to the setup, not only will it create a Configuration.ini file for you, but you will be presented with a more detailed installation wizard with more options, including an option to either specify a "free" edition, or enter a product key.
Here is a screenshot of the what the wizard will look like when it show a link to the configuration.ini file
On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will recreate the .OCA file when you load a project
requiring the control. This recreation process comes with a time
penalty.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.
My windows mobile app has a local database file (database.sdf). The file that is created when the user installs the CAB file in their device. The installation works fine but when I try to open the SDF with Query Analyzer or when the app tries to access the database I get a message.
"Access to the database file is not allowed" (25039)
When I checked the permissions using Windows Explorer (the device is docked), the file is marked Read Only. If remove the Read Only checkbox everything works fine, I can open, edit and add records to the database.
How I can make the file not Read Only by default?
You could verify the attribute programmatically during start-up of your application. In C#/.netcf it would be:
if (File.GetAttributes(path) & FileAttributes.ReadOnly == FileAttributes.ReadOnly)
File.SetAttributes(path, File.GetAttributes(path) & ~FileAttributes.ReadOnly);
In addition to the answer provided by yms, I would try to figure out why the file is being created as ready-only in the first place.
Is it created via some custom installer dll you added to the installation process? Or is it packaged up into the .CAB file via cabwiz or an installer project in VS?
If it's the former, check the source code of that installer library.
If it's the latter, check the source files. If you include the SDF in your Visual Studio project and have the project checked into some type of source control, it's likely that while it's checked into the source repository it's read-only on disk when it get's packaged up into the .CAB.
I know this is old, but if Andrew is actually using the .netcf, it doesn't have File.GetAttributes. Instead he should use
FileInfo info = new FileInfo(pathToFile)
if ((info.Attributes & FileAttributes.ReadOnly) == FileAttributes.ReadOnly)
info.Attributes &=~ FileAttributes.ReadOnly;
I have my installer and is working fine.
What I want to add more is that I want to show the work done by installer on installer screen (Example, installing Microsoft SQL Server 2005, we get the files being copied, moved, registry entry created,......)
Similarly I want to show this on my installer.
So can anyone help me on this to how to show all these at runtime on installer screen.
Thanks,
Sunil
Just copying my answer to the same question on wix-users list:
Use ProgressText element.
The 'Template' attribute is the place to put tokens to reflect the progress. See the standard InstallFiles action for example.
The table "ActionData messages" lists the possible tokens for this action.
Sample:
<ProgressText Action="InstallFiles" Template="File: [9][1]">!(loc.InstallFilesActionText)</ProgressText>
Outputs:
File: C:\Program Files\MyApp\bin\my.dll
etc.
Hope this helps,