I created a Visual Studio MSI Project that runs an custom EXE (which is good). In this exe, there is some code to add additional registry changes to add entries into Internet Options (mainly Local Intranet and Trusted Sites under Security). When the exe is run by itself (and in the debugger), it executes as expected (and puts the correct registry entries in their correct location). However, when the MSI executes the exe file, this part gets ignored even though it runs (I've added Console.Writelines everywhere).
I've been beating my head over this for 2 days and if anyone has had experience with this, a correct direction would be great.
I am using Visual Studio 2013.
Shelling out to an EXE from an MSI is not considered "good". As I recall, one of the many limitation of Visual Studio Deployment Projects (.VDPROJ) is that custom actions are scheduled with impersonation. If the MSI is being invoked from a standard user context UAC elevation won't help because the standard user context is impersonated.
If you want a reliable, best practices based installer, you should use the Registry table. Of course the problem there is another one of the annoying limitations of VDPROJ is that every registry value is a key file of it's own component and you quickly get into self repair hell.
I'd really suggest starting over with another toolset. I can think of several good ones.
I didn't realize that there is a "Registry On Target Machine" option inside of the MSI builder for Visual Studio. All I had to do is right click the project > view> Registry.
There I just had to map out the values in the right places.
Thank you for everyone who answered.
Related
I have two MSIs created using MS Visual Studio 2010.
Both MSIs created using same codebase, however, different Product Code and Upgrade Code.
Problem is once I uninstall the first application and try to open the second application from the shortcut exist in the start menu, it start the re-installation process.
Furthermore, If I check the actual installation folder of the second application in Program Files, all binaries exist and if I click on the Main Application EXE from there, it opens the second application without any issue.
Concern here is how to avoid re-installation process of the second application when I click on the shortcut exist in the start menu after un-installing the first application? Whats the relationship?
It's almost certainly not a re-installation process - it's a repair. There should be some MSIInstaller Application Event Log entries that say what appears to be missing. Perhaps there are some common files between the two separate MSI setups? If so, it seems that they are not shared properly. When you uninstalled that first product it removed something that is in use by the second product, so when you used a shortcut is repaired it. It doesn't need to be a file overlap - it could be a registry entry.
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
More fun and pain with Visual Studio. Visual Studio 2005.
About two months ago, I started an assignment. In my role, I cannot install or configure development software. Trust me this has given me plenty of heartburn. No IIS is involved here, just File Sharing.
That being said, when I first started I had a problem with my debugger not working. The debugger just stopped. I was able to get it working. Now the problem has returned and I am pulling every last hair on my head.
Almost none of my symbols loads. It can't find the PDB files.
In Debugger options, I checked the Symbol section.
My symbol file location entry is completely blank. ? I don't know why. I did not touch this prior to the problem occurring.
I have cleared the Temporary ASP.NET folders.
Example:
Here is my Module Output
CppCodeProvider.dll C:\Windows\assembly\GAC_MSIL\CppCodeProvider\8.0.0.0__b03f5f7f11d50a3a\CppCodeProvider.dll No No Cannot find or open the PDB file. 17 8.0.50727.762 12/2/2006 4:23 AM 6A510000-6A52C000 [1844] WebDev.WebServer.EXE: Managed
WebDev.WebHost.dll C:\Windows\assembly\GAC_32\WebDev.WebHost\8.0.0.0__b03f5f7f11d50a3a\WebDev.WebHost.dll No No Cannot find or open the PDB file. 3 8.0.50727.42 9/23/2005 4:20 AM 6D040000-6D050000 [1844] WebDev.WebServer.EXE: Managed
So I enabled the SHFUSION.dll in my versio of the the Framework I am using...
In my GAC, I can see this version of WebDev.WebHost.dll for example:
ProcessArchitecture(x86)
Public key token matches:
b03f5f7f11d50a3a
8.0.50727.42
I then see some custom dlls.
I should note, I created a new project. Recreated my files manually by importing them. The debugger worked 5 times and died.
I'm at a loss of what to do next?
The obvious has been checked: The project is set to Debug
Configuration Manager Configuration Debug Platform .NET Build : checked.
Web.Config:
I have attempted to manually attach to the Webdev process from the Debug window and that doesn't work.
I have googled this and this problem seems to occur quite a bit.
You mentioned that your symbol server settings are blank. Have you tried adding the Microsoft Symbol Server location?
Go to Tools -> Options -> Debugging -> Symbols
Add the following to the symbol file locations:
http://msdl.microsoft.com/download/symbols
You can also use this to point to more symbol locations. For instance, if you have a directory for all of the debugging symbols for your software, you could place the .pdb files there and add the directory to Visual Studio to load them.
Pick a directory for the symbols to save to and try again.
Yesterday, I reset my environment variables on my laptop from
VS2005 prompt, blew away the Temporary ASP.NET files and I was debugging again.
After 4 rounds of debugging it quit again. I cleaned the folders again, and I was debugging again.
It get's better. They replaced laptop today with a desktop.
I no longer have admin priviledges. A lot of common troubleshooting
steps are now off the table ( i.e. cleaning Temporary ASP.NET folders, installing
new symbols from MS site.)
Get this, first thing I did was download the code from our Subversion repository.
Built it. I was able to debug it 1 time.
I made some changes based on the problem I'm working on. 2nd time, debugger would not work.
I've been neutered as well as having to deal with this problem. Isn't life grand.
I'm beginning to wonder if the issue is not related to some folder permission/configuration of my account on the network. But I'm also considering a wide variety of tin foil hats as I pull out my hair. . .
Thanks for your help....
Visual Studio is probably installed in %ProgramFiles%. On Windows 7 or higher, you will need administrator rights to use programs like Visual Studio. Companies should trust their developers enough to give them accounts with Administrator rights.
If you're in the unfortunate situation of not having Administrator rights, you may be able to add the following registry key (or ask your IT department to add this key manually for you). Be sure to check that your Visual Studio 2005 installation path in the .reg file is correct.
Windows Registry Editor Version 5.00
; Run Visual Studio 2005 with administrator rights
; This is required to run / debug the program directly from the IDE
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Microsoft Visual Studio 8\\Common7\\IDE\\devenv.exe"="~ RUNASADMIN"
Recently, the SourceSafe integration into visual studio has started to perform badly because we have moved, and the SourceSafe "server" is located across a VPN which goes across a slow connection. This has made loading large projects in visual c++ 6 take 5+ minutes because it has to talk to the "server" for each project. Also, there are some bugs that are dangerous in the integration (the auto-checkout of certain shared projects will do a get latest on the wrong version of a branched file). This has caused me to want to disable the SourceSafe integration, however I have not found any menu option or uninstall option. Google has reported a few registry tweaks, but none of them seemed to work.
Does anyone know of an easy way to remove the SourceSafe integration from Visual C++ 6, without uninstalling SourceSafe altogether?
From http://support.microsoft.com/kb/236399:
Source code control software, such as
Microsoft Visual SourceSafe, that
integrates with the Visual C++
integrated development environment
(IDE) can be configured to connect to
a source code server during Visual C++
startup. In such cases, a loss in
network connectivity will cause Visual
C++ to start up very slowly. To
improve performance, either ensure
proper network connectivity or disable
the source code control software
integration with the Visual C++ IDE.
To do the latter, quit Visual C++, and
then use RegEdit.Exe to locate the
following registry key and set its
Disabled value to (DWORD) 0x00000001:
HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Source Control\Disabled
I followed this and it seemed to work upon trying it again. I think I might've had a second copy of visual studio running when I did it the first time.
Open the .dsp and .dsw file in a text editor, and remove the respective entries from the .dsp and the .dsw file. Also, delete the .scc files.
There is a Microsoft Knowledge Base article about how to do exactly this.
The gist of it is that you must manually edit the .dsw and .dsp files in a text editor, and remove a few other files lying around. See the article for more details.
If the solutions mentioned above fail for you do this:
Rename folder: \Program Files\Microsoft\%vs%\Common7\IDE\VS SCC
VS will complain once about plug in not being there and you say "Yes" to ignore it in perpetuity.
All files “got latest,” “read only,” and edited in VS, will make VS complain and offer to “override”, which works fine for me.
What do you gain:
Open VSS-linked solutions quickly without VS matching contents to VSS server.
Open VSS-linked solutions and EDIT the files at will without being bogged down in “check out” bs.
This makes using other distributed source control system on top of project tree with VSS bindings painless.
VSS client still works by itself just fine, including diff, checkout, checkin.
HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Source Control\Disabled
I followed this and it seemed to work upon trying it again. I think I might've had a second copy of visual studio running when I did it the first time.
Its working .....Thanks Ajay
What has worked for us, and is much easier, requires no registry/file editing by hand, and safer I think is this:
1) Exit Visual Studio completely.
2) Disconnect from the network (unplug the cable and turn off wireless, or disable the network adapters)
3) Open the VS6 workspace (DSW) for the project. When it starts up it will find it cannot connect with the VSS database it wants to and ask you about that...
4) Tell VS to never try to reconnect to the source control db in the future.
5) Done... VS does all the changes to THAT WORKSPACE/PROJECT setup for you. You are not disconnecting VS from source control in general (like a registry edit would do) and your not manually editing files.
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).