I have added an automation interface to an application I wrote. The type library is stored as a resource in the application, and on startup, the application calls RegisterTypeLib to register the type library automatically.
I just discovered that this call to RegisterTypeLib only works during development, where the application is launched from Visual Studio, because Visual Studio is running as administrator, and the application inherits this. When running the debug build from the command line, or when running the application as installed by the installer, the application is not running as administrator, and the call to RegisterTypeLib fails.
So I suppose I should register the type library during installation (which would also have the nice side effect of making the automation interface available without having to run the application first). The installer is a Windows Installer project in Visual Studio.
Is it possible to do achieve the effect of RegisterTypeLib during installation (and if yes, how)? When the installer solution is open, Visual Studio shows an editor called "Registry" wher one can add keys to the registry, but there's no way I can add each key separately - I need to somehow add the entire type library with a single call, like RegisterTypeLib does.
EDIT: After manuell's hint and some research of my own, the question boils down to this:
I need to call MyApp /RegServer from the installer (which will also create other required registry keys that aren't created by RegisterTypeLib); how exactly does one do this? I added an "Install" custom action in the Visual Studio installer solution, but haven't yet found out how to trigger it.
The usal way is to let the installer launch the application with the command line arguments /regserver or /unregserver. If you use a Framework (MFC/ATL), the handling of all the registration (unregistration) steps are done automatically.
If you want to do all by your self, check the arguments to "main", and call RegisterTypeLib. The Windows installer should launch your EXE with /regserver, if it knows that's a com server.
Related
I have created a windows based application in C# using visual studio 2008 which basically scans for the registry and then fixes the resulting errors. Now using the msi installer i have made a setup and it works fine. However i have met with a new requirement.
Usually after providing the setup to the user/client has to install the setup and when installed, in the installed folder there are lots of .dlls that i had used to create the project. But my requirememt is to create a single standalone .exe using which i wouldnt have to provide my users with the setup file. All i need to do is that using this single .exe file my whole project should execute and perform the same process of scanning and fixing the registry.
I also tried "ClickOnce Deployment in .NET Framework 2.0" and got the error "ClickOnce does not support the request execution level 'requireAdministrator'". and also have gone through the link
"ClickOnce does not support the request execution level 'requireAdministrator.'"
But still i feel that i would be comfortable if i can get a single standalone exe which can execute my windows forms application.
Is there any way to do it?
Any hint with this thing will be really helpful to me.
Thanks in advance
~Viknesh
There is similar questions on SO such as this and this however both suggest ClickOnce which I don't (can't) use.
I have started a new Setup project (InstallAllUsers=false) and have specified theApplication Folder to be [LocalAppDataFolder][ProductName]
which at install time points to
C:\Users\nonadmin\AppData\Local\Setup1\
When running the installer on Windows 7 as a non-admin I get this:
From my perspective it appears all the MSI does is copy the one text file to C:\Users\nonadmin\AppData\Local\Setup1\, something that could be done manually without this popup showing
The error message says something about 'unknown publisher' - does this occur for any msi/exe that simply runs? (even if it does nothing)
How can I avoid this dialog (a la ClickOnce) for non-admin users?
To avoid a consent prompt, you need to mark the package as "UAC compliant." (See "Guidelines for Packages" in the MSI SDK.) It looks like Visual Studio deployment projects don't support that bit so you'd have to modify the package in a post-build script (or use a different tool, like Wix that supports it directly).
Any package or executable that isn't Authenticode signed shows up as "Unknown publisher."
I need to execute a Console Application script after installing my application. Depending on the Windows version, it adds some data to the Registry.
How can I do this using a Visual Studio Setup Project?
Note:
I'm saying after because I read in How to execute custom action before installing files when using VS's Setup Project? that it isn't possible to do it before, but it doesn't really matter in my case.
Simply add the custom action under Install node. I don't really understand what you mean by "console application script", but if you mean a BAT file you can write a custom EXE which launches it through ShellExecute.
If you are using a DLL, make sure that "InstallerClass" custom action property is set correctly:
False for Win32 DLLs
True for .NET Installer Class actions
I am wondering about the need for an install wizard for my little Windows Forms application. No database access, just file access on a shared network drive.
I have seen times when an executable is sent in an email, copied to a desktop and used.
Other times when an 'install wizard' seems to be used to set up the application.
What dictates the need for this or not?
And if I want to use one - what needs to be added to my windows form app?
If your application is truly just an .exe file, it's probably okay to distribute it as-is without an installer. This might be preferable for more advanced users, because they won't have to worry about cleaning up a broken/unwanted install - they can just delete the file and be done with it.
On the other hand, most Windows users are used to working with installers, and having shortcuts automatically created on the desktop or Start->Programs. This is where an .msi can really help. Also, using an installer will usually put your application in the "Add or Remove Programs" control panel, which most people know how to use. Also, if your application is more than just a single .exe file (e.g. multiple .dlls and resource files), you'll probably want to use an .msi.
Creating an installer is easy, look at "Setup Projects" in Visual Studio.
An installer is almost always a good idea, because it can work out what dependencies your application has - which you may not even be aware of.
It also looks more professional and users will have more confidence in it.
There's an open source installer called NSIS that's pretty good, if you find the Visual Studio setup wizard too clunky, as I sometimes have.
Sometimes simply copying a file just isn't sufficient, this is when you need a setup program.
Checking if the correct version of .NET is installed
Installing C++ runtime dependencies
Creating a desktop shortcut
Setting up "default" configuration data
Adding exceptions to the Windows Firewall
Preventing installation on unsupported systems such as Windows 95/98/ME
etc, etc.
If your program is a stand-alone application with no dependencies and can run on a stock-standard install of Windows 95... then you don't need to worry about setup ;) But if your app has any external dependencies then you want to spend some time on setup.
I'm using a VS 2008 Setup and Deployment project to deploy a mixed managed / unmanaged application. I've had trouble registering mixed-mode DLL's using the built-in registration property ("vsdraCOM" enumerated value of the "Register" property.) As a workaround, I've added a .NET custom install assembly (with a class that derives from System.Configuration.Install.Installer.) I'm certain that that class is running and a number of operations successfully install and uninstall through code in that assembly, including executing the Dll(Un)RegisterServer entry point of a number of assemblies.
However, one DLL is not successfully registering. It is the only DLL that depends on some 3rd-party redistributable assemblies that want to be installed to the GAC. I have those assemblies installed to the GAC thanks to the built-in support for that in VS 2008's setup and deployment projects, and I know that is working. I've confirmed that what is happening is that the custom action is executing before the installer executes the GAC installation.
Whew. So my question is, is there a way to force the installer to execute the GAC installation before executing the custom action? Is there a way to use the "Condition" property of the custom action to do this? If not, what's my best alternative? Capturing the registry entries from the DLL and adding them to the registry settings for the installer (don't like this because someone may add new COM servers to the class in the future)? Using .NET code to install the assembly into the GAC manually (don't know how to do that yet)?
Thanks,
Dave
The setup projects you can create in Visual Studio are very limited. It only allows custom actions to be scheduled at 4 points. However, MSI allows custom actions to be scheduled at any point in the process with some restrictions on what they can do.
My first solution is to stop using Visual Studio 2008 as your setup development tool. The Visual Studio team has tried to abstract away all the complexity of creating an install. However, in the process they have also taken away all the flexibility of MSI. Wix, InstallShield, or Wise are much better products for anything but simple installs. I started off using Visual Studio for our installs and it ended up being too much work. There was always one more workaround to be implemented and its side effects to be dealt with.
If you can't switch technology, then you will need to learn how to manually modify the resulting MSI file. In your case you will need to modify the InstallExecuteSequence table, http://msdn.microsoft.com/en-us/library/aa369500(VS.85).aspx. You can do this manually through Orca, http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx or through the MSI API http://msdn.microsoft.com/en-us/library/aa372860(VS.85).aspx. Make sure to download Orca and run the validation scripts against your install. The scripts point out numerous problems that fixing will save you countless hours when deploying to customer machines.