We are using Windows Installer / MSI not ClickOnce.
We have followed this detailed Microsoft article on creating a Windows Installer for our
VSTO Outlook Addin:
Deploying a Visual Studio Tools for the Office System 3.0 Solution for the 2007 Microsoft Office System Using Windows Installer
It's fine, but always with these long, complex, detailed scripted setup instructions there's the problem of knowing what is safe to customise to fit our own circumstances.
In our cases we're using VS2010 and VSTO4 and the instructions are for VSTO3. So the launcher we created using those instructions complains about the missing VSTO3.
What do we have to change? And what do we insert for VSTO4? Here are the relevant extracts from the article:
6. In the Properties window, perform the following tasks.
a) Set the value of (Name) to Search for VSTO 3.0 Runtime.
b) Change the value of Property to VSTORUNTIME.
c) Set the value of RegKey to Software\Microsoft\vsto runtime Setup\v9.0.21022
d) Leave the Root property set to vsdrrHKLM.
e) Change the Value property to Install.
7. In the Launch Conditions(ExcelAddInSetup) editor, select the Condition1 launch condition, right-click the condition and select Properties Window.
8. In the Properties window, perform the following tasks.
a) Set (Name) to Verify VSTO 3.0 Runtime availability.
b) Change the value of the Condition property to the following VSTORUNTIME = "#1"
c) Leave the InstallURL property blank.
d) Change the value of the Message property to The Visual Studio Tools for Office 3.0 Runtime is not installed. Please run Setup.exe.
It's this last error (our own launch condition error, if you like) which is firing on the target machine.
The Visual Studio Tools for Office 3.0 Runtime is not installed.
Please run Setup.exe
It appears there's an updated guide here:
http://msdn.microsoft.com/en-us/vsto/ff937654.aspx
The same instructions, but updated for VSTO4.
Related
I'm creating an OpenEdge Progress-4GL application, based on a window, where I like to add a tabpage. In order to do this (as there is no tab page control in the palette), I've tried to add the OCX (ActiveX) control "Microsoft TabStrip Control, version 5.0 (SP2)". However, when I try this I get the following error message:
Messagebox title: AB
Messagebox content:
CtrlFrame
Unable to create control.
Het licentie bestand voor genoemde ActiveX control is niet gevonden.
The last sentence is in Dutch, freely translated it means: "The license file for mention ActiveX control is not found."
What should I do in order to be able to add the mentioned ActiveX control to my window?
Or, even better: is there a standard "tabpage" control I can use for creating Progress-4GL basic Windows-based applications?
Edit after more further investigations
In the meantime from the directory C:\Windows\SysWOW64\ I have launched the command regsvr32 comctl32.ocx with following results:
Launched as a regular user : the command fails with error number "0x8002801c". This seems to be due to user permissions.
Launched as an administrator : the command succeeds but still it seems not to be possible to use the mentioned control.
Edit after installation of Visual Studio
The problem seems still not to be solved, even after having installed Visual Studio 2019, version 16.8.3. The following components are installed:
Workloads :
Web & Cloud (4)
ASP.Net and web development
Python development
Desktop & Mobile (5)
.NET desktop development
Desktop development with C++
Universal Windows Platform development
Other Toolsets (6)
.Net Core cross-platform development
Individual components : Development activities (filtered on "Basic")
C# and Visual Basic
Apparently the required license is not in the installation. What do I need to add?
The error message says that you don't have a developer license for that Active X Control. Some (old) Visual Studio installs provide that license.
Your options are:
a) obtain that license through a Visual Studio/Visual Basic license that still has Active X Support, like VB6, note, that Microsoft dropped that from Visual Studio probably 15 years ago.
b) find a different tab folder Active X Control (that is still supported by a vendor). The Codejock components are known to work well in the AVM: https://codejock.com/products/controls/?2yn6s14z=p1z
c) get into ADM2 framework from Progress Software. That provides a tab folder purely written in ABL (not pretty). But learning ADM2 in 2021 seems really painful. It's no longer a maintained by Progress Software
d) Switch to Progress Developer Studio and start using GUI for .NET (https://docs.progress.com/de-DE/bundle/openedge-gui-for-net-primer-117/page/Object-oriented-Programming-in-ABL.html). You can build UI's based on (any) .NET WinForms Control based on GUI for .NET. However, the OpenEdge Studio does not provide a graphical designer for that.
e) Build your own pure ABL tab folder based on images and buttons.
I've created a project on VB6 at but when I am opening it on VB8, it shows the following error:
How to fix it?
As listed by GSerg in the comments, this appears to be a known issue documented in Microsoft Knowledge Base article 896292: You receive a "The remote procedure call failed" error message when you upgrade a Visual Basic 6.0 project to Visual Studio .NET 2003 or Visual Studio 2005 on Windows Server 2003 SP1 or on Windows XP SP2
To reproduce the solution here:
Cause
This behavior occurs because the VBU.exe tool has compatibility issues with the Data Execution Prevention (DEP) option.
Note: The VBU.exe tool starts when you upgrade the Visual Basic 6.0 project by using the Visual Basic Upgrade Wizard in the Microsoft Visual Studio .NET IDE.
Workaround
To work around this behavior, add the VBU.exe tool to the DEP exclusion list. To do this, follow these steps:
Click Start, click Control Panel, and then double-click System. The System Properties dialog box appears.
Click the Advanced tab, and then click Settingsunder Performance. The Performance Options dialog box appears.
Click the Data Execution Prevention tab. Verify that the Turn on DEP for all programs and services except those I select option is selected
Note By default, the Turn on DEP for all programs and services except those I select option is selected in Microsoft Windows Server 2003 Service Pack 1 (SP1).
Click Add. Locate and then click to select VBU.exe. Click Open.
In the warning box, click OK. VBU.exe now appears in the DEP program area.
Click Apply, and then click
OK. A dialog box appears that states that you must restart the computer for the setting to take effect. Click OK.
Try do divide your project to small projects(or comment large part of your project) a try again in each small project.
The idea is to find the function that is production the error.
My intuition is telling me that maybe is a DLL or OCX problem. Try to see all the external DLL or OCX calls and remove from the original project and try again the upgrading.
Most developers who move their VB6 projects to .Net do not even try to port them over. Even with third-party "conversion" software, the effort can be incredibly tedious. So much so, that most developers simply re-write the application completely. Consider it a move to a different language. In fact, some developers use that opportunity to port it to C# instead. I'm a die-hard VB6 user/fan but were I to attempt to port my 200 form accounting application, I'd just re-write it in C#. I started porting it, tried third-party conversion apps, just wasn't worth it.
I have a Setup Project in Visual Studio 2010 which creates a .msi installer. I am wondering if it is possible to add some logic to check some conditions. e.g if there is my software installed yet.
Thanks,
This is done through installer properties. You can set them and check them against values. They are just like variables in code.
However, Visual Studio is limited when it comes to custom installation logic. If you don't figure out how to do what you need, give us more details.
As a side note, launching the installer for an already installed product makes it go into maintenance mode (Modify, Repair and Remove options). So you don't need to check if your application is already installed.
You need to add installer class to one of your library or assembly. In Visual Studio, attach installer events to custom action. See how http://www.simple-talk.com/dotnet/visual-studio/visual-studio-setup---projects-and-custom-actions/ or here http://msdn.microsoft.com/en-us/library/d9k65z2d.aspx
I have the following situation:
Installed my application using ordinary .msi
Run the application from the start menu
Right click on the icon in the task bar and pin it.
Now, I can use the pinned item/short cut to start my application but after I update my app using another .msi file, clicking on the pinned item shows this error:
'Problem with shortcut' - The parameter is incorrect.
I have checked the short cut and as far as I can see it points to the same directory/file as the previous version. (the new version has the same files/location).
I assume that there is some versioning/Program Files magic happening that causes this issue but haven't found any good information on the net.
Some more information:
The application is written in C# .NET 3.5 SP1
The msi is created using a Setup Project in Visual Studio 2008 SP1
I use a custom build tool to integrate the msi build and set the ProductCode and PackageCode to a new GUID for every version.
The update seems to work fine otherwise. The old version is uninstalled, the new one installed correctly.
Anyone got a clue?
My guess is the default Application ID is changing. If you intend to update this app with msi's regularly once it's "in the wild" then set your own Application ID. If this is a one time thing, then just unpin and repin it and carry on as normal.
Setting the Application ID is easy if you're using the Windows API Code Pack. Are you?
Kate
See this article about ProductCode and PackageCode: http://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
It explains how ProductCode and PackageCode interact at install time and how to configure your setup project to properly apply the .msi as an update.
Right now, I am creating an msi and a setup.exe using the Visual Studio. It works quite well... till recently.
I recently added a new dialog box with a Combo Box Control to the msi. Now when I install the app directly using the msi, everything is works just fine.
But when I run the Setup.exe, the ComboBox is not displayed correctly. It only displays one element at a time in the drop down list. All the elements are still there, and I can even select them using the Up/Down keys or the letters ('S' for SQL Server, for instance).
Has anyone seen this kind of a problem before? Moreover, when I use InstallShield to create the setup, the exe created by InstallShield again runs fine.
So I suppose I need to fix the one with Visual Studio. Any ideas how to do fix the visual studio bootstrapper?
Platform:
Using Visual Studio 2005 for the builds.
OS: Windows XP SP3.
The build machine has Windows Installer 4.5 installed, but its not a pre-req.
The msi itself runs fine with Windows Installer 3.
Also, the problem is not that the setup exits too fast, or that it doesnt install properly... It does. The only issue is that the Combo Box is not displayed properly and that might confuse some users.
What version of Visual Studio are you working with? Are you using VS2008 SP1?
There is a known issue with the bootstrapper from this version of Visual Studio being introduced in SP1. Maybe you are facing the same problem? You can check the details on this issue on Microsoft's connect site:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=369138
There is also a discussion going on here: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/3731985c-d9cc-4403-ab7d-992a0971f686/
EDIT: Actually the thing that was fixed in SP1 could also solve your problem. The difference in SP1 is the way that the bootstrapper launches the actual MSI installer. Prior to SP1 the MSI installation (i.e. msiexec) was started as a child process of the bootstrapper (i.e. setup.exe). Now it is started as a non-child process and setup.exe returns as soon as the bootstrapping process is finished and the MSI is launched. You can see the difference also because before the buttons in the setup wizard were not using the Windows XP / Vista theme style.
I was unable to exactly find out WHY the VS bootstrapper was behaving the way it was, but grabbing another Setup.exe from another project (not built using VS) fixed the problem.
[I was under the impression that the Setup.exe has some kind of identifying information or a link to the MSI that it is supposed to kick off. Apparently not. Just throwing in the other setup.exe did the trick.]
Hope this helps someone.
In the .MSI itself what is the height setting of the combo box control? The height property controls the combined height of the selection area and the drop area. If it is set too low then you'd get the problem behavior you're describing (though that would not explain why sometimes it appears correct).