How Do I Prevent the Installer from Running when Application Data Files are Removed? - visual-studio-2005

I have an application written in VB.Net with Visual Studio 2005. The application allows the user to create and save project files. When I distribute the application, I include some demo project files, which I install in the common application data folder.
XP - C:\Documents and Settings\All Users\Application Data
Vista & 7 - C:\Program Data
I have discovered an unexpected behavior -- if any file in the common application data folder is removed, and the application is run from the start menu, then the install procedure will start and attempt to restore the missing file(s). If the MSI file no longer exists at its original location or has been changed, then the application will fail to run. I perceive that this is a "feature", but it is one I don't want. Can anyone tell me what is going on and how I can avoid it?
Some more details:
I created the setup package by using a Visual Studio deployment
project.
This behavior will not occur if I launch the EXE directly. I
expect, therefore, that the behavior has something to do with the
start menu shortcut. I've noticed that the shortcut isn't a normal
shortcut -- it doesn't have a "Target Location".
All advice is appreciated.
-TC

I have learned that this behavior involves something called "Install-on-Demand" (aka "Self Heal"). The unusual shortcuts created by the setup package are called "Advertised Shortcuts". Now that I have a name for the problem, it is easy to find information on how to fix it. Notably:
http://msdn.microsoft.com/en-us/library/aa368297.aspx
http://groups.google.com/group/microsoft.public.dotnet.distributed_apps/browse_thread/thread/401847045f104af3
http://blog.jtbworld.com/2007/11/enable-target-and-change-icon-of.html
Those pages contain a wealth of information. For the convenience of others who may stumble upon this post, I will summarize what they say:
Advertised shortcuts are special shortcuts which do some fancy things. Most notably, they reinstall damaged application before launching their target. There is some debate over whether they are good, evil, or harmless. In my opinion, they do something most users don't expect, and that makes them evil. Therefore, I'd like to disable them for my application.
Visual Studio setup projects automatically create MSI packages which generate advertised shortcuts by default. It is easy to override that default when installing the MSI package by using DISABLEADVTSHORTCUTS=1 as a command-line argument for Setup.exe. Also, with a utility like Orca, you can manually change the default by inserting DISABLEADVTSHORTCUTS=1 as a property of the MSI. However, if you want Visual Studio to automatically create MSI packages which don't create advertised shortcuts, that is harder. I did it this way:
First, I created a VBS file using the DisableAdvt code provided by Gary Chang in one of the links above (I've repeated that code below). Just create a text file, paste in the code. and save it as DisableAdvt.vbs.
Then, create a post-build event for your setup project. The exact syntax will depend on your file locations. Because my DisableAdvt.vbs is in a "Tools" subfolder of the solution folder, my post-build event looks like this:
"$(ProjectDir)..\Tools\DisableAdvt\DisableAdvt.vbs" "$(BuiltOuputPath)"
That's all I had to do. It works like a charm.
-TC
Some notes:
In Visual Studio 2005, Build events are accessed differently for setup projects than they are for other types of projects. Click on the project name in the solution explorer, then look for PostBuildEvent in the Properties pane.
Orca is a utility that can be used to manually insert the DISABLEADVTSHORTCUTS property into the MSI file. With my approach, Orca is not necessary. However, it is useful for verifying that the build event is making the expected change.
http://www.technipages.com/download-orca-msi-editor.html
In the build event, the misspelling "BuiltOuputPath" is intentional.
Here is Gary Chang's DisableAdvt.vbs code (note that I fixed a typo on line 21 -- Very important!):
Option Explicit
Const msiOpenDatabaseModeTransact = 1
Dim argNum, argCount:argCount = Wscript.Arguments.Count
Dim openMode : openMode = msiOpenDatabaseModeTransact
' Connect to Windows installer object
On Error Resume Next
Dim installer : Set installer = Nothing
Set installer = Wscript.CreateObject("WindowsInstaller.Installer") :
CheckError
' Open database
Dim databasePath:databasePath = Wscript.Arguments(0)
Dim database : Set database = installer.OpenDatabase(databasePath, openMode) : CheckError
' Process SQL statements
Dim query, view, record, message, rowData, columnCount, delim, column
query = "INSERT INTO Property(Property, Value) VALUES ('DISABLEADVTSHORTCUTS', '1')"
Set view = database.OpenView(query) : CheckError
view.Execute : CheckError
database.Commit
If Not IsEmpty(message) Then Wscript.Echo message
Wscript.Quit 0
Sub CheckError
Dim message, errRec
If Err = 0 Then Exit Sub
message = Err.Source & " " & Hex(Err) & ": " & Err.Description
If Not installer Is Nothing Then
Set errRec = installer.LastErrorRecord
If Not errRec Is Nothing Then message = message & vbLf & errRec.FormatText
End If
Fail message
End Sub
Sub Fail(message)
Wscript.Echo message
Wscript.Quit 2
End Sub

Related

How to solve VB6 forms crashing with Unload Me in Windows 10?

I am trying to install a VB6 application in Windows 10 computers, but when I load a child form and then unload it, the program crashes. If I start the application as Administrator from the shortcut, I can load and unload everything without issues. Have you experienced this before?
So far I've tried the following:
Started the .exe directly as Administrator. Not working.
Checked the Run As Administrator checkbox in the contextual menu (Properties / Compatibility) of the .exe. No good.
Created a .reg file to affect the HLKM\ ... \AppCompatFlags\Layers keys. Nada.
Tried affecting both the HKLM AND HKCU keys. Thank you, next.
Checked if some Recordset or variable was filled or active. Everything empty.
Tried Unload [name of the form] instead of Unload Me for one of the forms. Same result.
Part of the Unload code for one of the forms is as follows:
Private Sub cmdSalir_Click()
On Error GoTo ErrHandler
Dim frm As Form 'Identifica las formas a cerrar
For Each frm In Forms
If Not frm Is frmPoliza And Not frm Is MDIPrincipal Then
If Not frm Is frmAsegNoReclam And Not frm Is frmEndosoMedico Then _
Unload frm
End If
Next frm
gsPlan = ""
gmstrInstPagoInd = ""
gmstrCondEnv = ""
If IsFormLoaded("frmCotiza") = False Then
'gbInicio = True
End If
Unload Me
ErrHandler: 'APM 2019-01-31: Captura el error que se provoca al descargar la forma
If Err.Number <> 0 Then
MsgBox "OcurriĆ³ un error al cerrar: " & Err.Number & " - " & Err.Description, vbOKOnly
End If
End Sub
It is important to say that WinXP's installations are working correctly, but in 2 Win10's computers the error was replicated, so I'm guessing either Win10's security policies or the way the installation package is made has something to do with this.
If you can help me with this issue, I will appreciate it greatly.
Thank you,
Tony.
If the issue is that you need to run with elevated rights, then I suggest you declare that in you application manifest such that the user is prompted grant that. You can either create a separate manifest file or embed it. See here for details:
How do I create a manifest file in Visual Basic 6.0?
So I told the client about this issue, and decided to have the program virtualized in XP better than adapted to x64. Not the closing I wanted, but a closing after all.
Thank you all for your efforts.
Not sure if this will fix the specific problem but have found that running the application in Windows 8 Compatibility Mode on Windows 10 helps with issues like this. Worth a try.

Add Visual Studio 2010 custom property for .msi installer

How do I add a custom property in visual studio 2010 for an .msi generated at build time.
The .msi file should have a property named "BUILDARCHITECTURE". If it's not difficult this property should be automatically changed to x64 or x86 when I change the build platform.
If this is not possible I can just hardcode it to x86 ( it will be deployed on 32 bit machines ).
In Orca I can just go to the Property Table then just right click and add row and it works.
But I need to add it automatically at build time in VS2010.
Best Regards
So after some research I've gone with a similar approach like Phil's.
Meaning I added a post build event :
set msiFile=$(OutDir)\setup.msi
if "$(Configuration)" == "Release" (
wscript $(SolutionDir)\..\Build\AddCustomProperty.vbs %msiFile%
VBS Script :
set o_installer = CreateObject("WindowsInstaller.Installer")
set o_database = o_Installer.OpenDatabase("path_to_your_msi", 1)
s_SQL = "INSERT INTO Property (Property, Value) Values( '<CustomProperty>', '<custom_property_value>')"
Set o_MSIView = o_DataBase.OpenView( s_SQL)
o_MSIView.Execute
o_DataBase.Commit
The script was taken from : Need a way to add one property to the msi properties table in setup project in VS2010
You can do it with a post-build step, and I'd start with WiRunSql.vbs from the Windows Kit SDK. It's a script that takes a SQL statement to update an MSI file. You want a SQL something like:
INSERT INTO `Property` (`Property`.`Property`, `Property`.`Value`) VALUES ('BUILDARCITECTURE', 'whatever')
However why do you need it there? An MSI knows its architecture with the VersionNT64 property, so inside the MSI you just use that, or pass it to your custom actions or whatever.
From outside the MSI you can get the architecture from the summary info stream template property, as in this dumb vbscript:
Option Explicit
Dim installer
Set installer = CreateObject("WindowsInstaller.Installer")
Dim sumInfo : Set sumInfo = installer.SummaryInformation("another.msi", 0)
dim someproperty
someproperty = suminfo.Property(7)
msgbox someproperty
set suminfo = Nothing
set installer=nothing

InstallShield - Get version of a file

I am using InstallShield 2010 and was wondering if anyone knows how to do the following:
I want to get the version of my main exe within my installer and make it the name of my setup.exe InstallShield is generating. Any idea how to do that?
There are several ways you could do this....depending on your IS project type (MSI, installscript, etc.)
1) create a variable such as Product_Name in the Property Manager, set it in your installscript and retrieve it to modify your *.exe name
2) Using SQL, you can programatically get the product_name and set the *.exe name. Search the Direct Editor (Installation Designer -> Additional Tools -> Direct Editor) for the exact location of the table/value you need. For example (below), using VBScript, I modify the path to the installation root of the files I pull into the IS project. Similarly this can be done for any table in the IS Direct Editor. Using a tool such as Visual build Pro I believe would help you out as well. It's well worth the ~$100!
Set oMSI = CreateObject("WindowsInstaller.Installer")
On Error Resume Next
' open ISM file in transacted mode
Set oDB = oMSI.OpenDatabase("C:\Path\to\myProject.ism", 1)
strQuery = "Select * FROM `ISPathVariable` WHERE `ISPathVariable`.`ISPathVariable` = 'InstallTreeFolder'"
'////////////////////////////////////////////////////////////
'// Update Path Variable
' fetch the one and only samplesource record
Set oView = oDB.OpenView(strQuery)
oView.Execute
Set oRec = oView.Fetch
' change field 2, the Value field
oRec.StringData(2) = "%INSTALL_TREE_ROOT%"
' update the changed record
oView.Modify 2, oRec
' close the view, commit changes, clean up
oView.Close: oDB.Commit: Set oMSI = Nothing
I was able to use the Automation services to accomplish this, which is the programming interface for InstallShield. Whenever I build my project in Visual Studio for my exe I run an exe in the Post-build that sets the InstallSheild project to be the same version.

Any quick way to run a file in Visual Studio?

Is there any quick way to run a file(.cs) in VS 2008 with a Main method ?
Often you'd want to test some mockup code, Going Alt+f7(Project->ProjectName Properties) and changing the Startup object from a dropdown list is quite cumbersome.
Get yourself the SnippetCompiler, it's made to run snippets (not inside of VS, but close enough) and may help you.
What about instead of mockups, writing those as unit tests. You can run those quickly without changing entry points. And the tests could stick around for later changes. Instead of writing to the Console, you would use Asserts and Trace Writes.
To compile one file C# programs I have created a .bat file, on which I drag and drop a .cs file and get a .exe in .cs file directory.
SET PATH=%PATH%;C:\WINDOWS\Microsoft.NET\Framework\v3.5
cd %~d1\
cd "%~p1"
csc %1
You can use this .bat file in a Visual Studio macro to compile active .cs file and run the application.
Sub RunCS()
If Not ActiveDocument.FullName.EndsWith(".cs") Then
Return
End If
REM Path to batch file
Dim compileScript = "C:\dev\compileCS.bat"
Dim compileParams As System.Diagnostics.ProcessStartInfo
compileParams = New ProcessStartInfo(compileScript, Chr(34) & ActiveDocument.FullName & Chr(34))
Dim compiling As System.Diagnostics.Process
compiling = System.Diagnostics.Process.Start(compileParams)
compiling.WaitForExit()
Dim programFile As String
programFile = ActiveDocument.FullName.Substring(0, ActiveDocument.FullName.Length - 3) + ".exe"
Dim running As System.Diagnostics.Process
running = System.Diagnostics.Process.Start(programFile)
End Sub
This will run only programs for which all code is in one file. If you want to quickly change projects instead, you can change your solution's Startup Project to Current selection
I keep a sandbox solution around that has a console project and other tiny project types that I use frequently. Snippet Tools are nice but usually don't come with the whole Visual Studio shebang like debugging etc.
Snippy, originally by Jon Skeet (who lurks on here I believe) and further developed by Jason Haley.

"SVN Blame" plugin for VisualStudio

I found this question but the referenced options don't say anything about supporting "blame". What I'm looking for is an integrated way to ask "Who edited the line under the cursor last?".
I know most/all SVN clients give this in some form but I'd like something that makes it easy enough that I can do it on a whim: "Humm, who wrote that? [tap tap] Oh him."
The daily builds of AnkhSVN 2.0 have a completely new annotate (blame) implementation inspired by the TFS annotate feature.
(source: qqn.nl)
Not really visible in these screenshots, but it uses the Visual Studio editor for syntax coloring, etc. (You can see the sizeof() in the right bottom of the next image is blue). As you can see in the second picture it also allows several commands on the revision regions in the left bar.
It currently doesn't implement the jump to active line. But you can use the Visual Studio goto line (Ctrl+G) command in it. (You might be able to script this in a macro)
The easiest way to start annotate is right click on the editor ->Subversion->Annotate.
(source: qqn.nl)
[Update 2009-02-03: This feature is now commonly available in the new Stable release]
I wrote a Visual Studio macro to get line number info and pass it to tortoiseproc.exe (which is part of TortoiseSVN)
Take a look at the parameter info:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html
Here is my macro:
Sub Blame()
sCurrFileFull = DTE.ActiveDocument.FullName
Dim activeDoc As Document
activeDoc = DTE.ActiveDocument
Dim nLine As Integer
nLine = activeDoc.Selection.CurrentLine
sShellCommand = sTorEXE & " /command:blame /startrev:1 /endrev:-1 /path:""" &
sCurrFileFull & """ /notempfile /line:" & nLine.ToString()
Shell(sShellCommand, AppWinStyle.MaximizedFocus, False)
End Sub
I use a set of external tools wired to TortoiseProc.exe to perform SVN operations like log, diff, blame, revert, commit, update, etc. Then I create toolbar shortcuts to these external tools so that I have all the basic SVN operations accessible within the IDE.
Here are the steps to create a button to do a blame on the current file:
Go to tools -> external tools and click "Add"
Enter whatever title you want (e.g. "Blame")
For the command, enter the following (the path will be different if you installed TortoiseSVN to a different directory): c:\Program Files\TortoiseSVN\bin\TortoiseProc.exe
For the arguments, enter the following: /command:blame /path:"$(ItemPath)" /notempfile
For the initial directory, enter:$(ItemDir)
Now, whenever you have a file open, simply go to tools -> Blame and it should generate the Blame in a popup window. You can also customize the toolbar and create a shortcut for this external tool to make it even easier.
In VisualSVN supports blame to some extent - you can right-click on a file and select "Blame". However, it pops up a new window, which may not be as integrated as you want.
Here's a working version of crashmstr's and Derek Dahmer's macro code:
Sub Blame()
Dim sCurrFileFull = DTE.ActiveDocument.FullName
Dim activeDoc = DTE.ActiveDocument
Dim nLine = activeDoc.Selection.CurrentLine
Dim sTorEXE = "TortoiseProc.exe"
' Add path if you don't have TortoiseSVN on your PATH
Dim sShellCommand = sTorEXE & " /command:blame /startrev:1 /endrev:-1 /path:""" & sCurrFileFull & """ /notempfile /line:" & nLine.ToString()
Shell(sShellCommand, AppWinStyle.MaximizedFocus, False)
End Sub
As per Derek Dahmer's instructions, add it to a new or existing macro module using the Tools > Macros > Macro IDE.
For easy access, I added the macro to my code window context menu:
Customize > Commands > Context menu > Editor Context Menus | Code Window
Add Command > Macros > Find your macro
Modify Selection > Name: Bla&me
Having it in the context menu enables easy keyboard access, but you can, of course, add a keyboard shortcut to it as well. I have it on Ctrl-Shift-M, which is not used by anything useful by default :).

Resources