I am trying to install visual c++ 2013 with bootstrapper, so inside the bundle tag i am using following code to install visual c++ 2013 as follows
<ExePackage Id="VC2013" Cache="no" Compressed="no" PerMachine="yes" Permanent="yes" Vital="no" InstallCommand="/q" SourceFile=".\vcredist_x862013.exe" />
currently it will install always, irrespective of whether it is installed or not, how can i put check for whether it is installed or not?
In your bundle, add the following lines:
<util:RegistrySearch Id="VCRedistTest64" Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID_HERE}" Result="exists" Variable="VCR64Present" Win64="yes"/>
<util:RegistrySearch Id="VCRedistTest32" Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID_HERE}" Result="exists" Variable="VCR32Present" Win64="no"/>
Replace the {GUID_HERE} tags with the correct GUID for Visual C++ 2013. To find this, on a machine with Visual C++ already installer, open your registry and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
In this key there will be several subkeys, where each subkey corresponds to one software package currently installed. Find the key which corresponds to the Visual C++ 2013, and copy the key name, which is the GUID you need to insert into the above code.
Finally, change your Exepackage element to:
<ExePackage Id="VC2013" Cache="no" Compressed="no" PerMachine="yes" Permanent="yes" Vital="no" InstallCommand="/q" SourceFile=".\vcredist_x862013.exe" DetectCondition="(VCR32Present OR VCR64Present)/>
This will allow Windows to detect if Visual C++ is already installed, and will prevent your installer from re-installing it.
Also, add the following to the top level "Wix" tag:
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
Related
I am working on a custom test adapter for Visual Studio 2017. How can I configure Visual Studio to debug the test adapter without having to use a hack such as adding Debugger.Launch() in my adapter code?
Microsoft Child Process Debugging Power Tool
Install the Microsoft Child Process Debugging Power Tool which was created by an employee at Microsoft. This allows you to configure the Visual Studio debugger to attach to child processes (which is how vstest.console.exe executes tests)
Once installed, open your solution and enable child process debugging:
1) Go to the child process debug settings at the following Visual Studio Menu location: Debug -> Other Debug Targets -> Child Process Debugging Settings...
2) Enable child process debugging: true and Save
3) Optionally persist the settings using the dropdown so that this setting can be checked into source control
If you choose to persist the settings, your settings file might look something like this:
<?xml version="1.0" encoding="utf-8"?>
<!-- EngineFilter Guid was found here: https://blogs.msdn.microsoft.com/martintracy/2006/05/16/debug-engine-guids/ -->
<ChildProcessDebuggingSettings IsEnabled="true" xmlns="http://schemas.microsoft.com/vstudio/ChildProcessDebuggingSettings/2014">
<DefaultRule Attach="false" />
<Rule IsEnabled="true" ProcessName="TE.ProcessHost.Managed.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.discoveryengine.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.discoveryengine.x86.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.executionengine.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
<Rule IsEnabled="true" ProcessName="vstest.executionengine.x86.exe" EngineFilter="{92ef0900-2251-11d2-b72e-0000f87572ef}" />
</ChildProcessDebuggingSettings>
Once this has been setup, you then just need to make sure your project is setup to debug with vstest.console.exe. The key point here is making sure that you enable native/unmanaged debugging, otherwise the child process debugging tool wont work.
New csproj System
Edit or create a launchSettings.json file to look similar to this:
{
"profiles": {
"DebugTestAdapter": {
"commandName": "Executable",
"executablePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Common7\\IDE\\Extensions\\TestPlatform\\vstest.console.exe",
"commandLineArgs": "Tests.dll --ListTests --TestAdapterPath:.",
"workingDirectory": "C:\\Projects\\TestAdapter\\Tests\\bin\\Debug\\net46"
}
}
}
Modify your csproj file to contain the following property, which enabled native debugging:
<PropertyGroup>
<EnableUnmanagedDebugging>true</EnableUnmanagedDebugging>
</PropertyGroup>
Old csproj System
In the debug properties page of your project, set the following settings:
Start external program:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\TestPlatform\vstest.console.exe
Command line arguments:
Tests.dll --ListTests --TestAdapterPath:.
Working directory:
C:\Projects\TestAdapter\Tests\bin\Debug
Enable native code debugging:
Set this value to true
I understand this is an often asked question, however after days of research I've not found an answer to this particular problem.
I have a new ASP.NET 5 (Core 1.0) MVC template that I'm trying to add a package to however each and every time I get in the Package Manager output:
Response status code does not indicate success: 407 (Proxy Authentication Required).
and the following at the top of solution explorer:
my settings look fine and I am able to browse packages in the 'Manage Packages for Solution' screen.
I understand I'm being requested to supply credentials so where do I enter them? On the other hand all other applications on my machine have validated internet access, so why should I?
Any ideas / pointers are very welcome.
Visual Studio 2015 - 14.0.24720.00 Update 1
NuGet Package Manager for Visual Studio 2015 - 3.3.0.167
Top section of Package Manager output:
Installing NuGet package AutoMapper.4.2.1.
Successfully installed 'AutoMapper 4.2.1' to CustomerPortal
========== Finished ==========
PATH=.\node_modules.bin;%PATH%;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External\git
C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\dnx.exe "C:\Users\medmondson.dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-update1\bin\lib\Microsoft.Dnx.Tooling\Microsoft.Dnx.Tooling.dll" restore "M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal" -f "C:\Program Files (x86)\Microsoft Web Tools\DNU"
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
GET https://www.nuget.org/api/v2/
GET http://packages.nuget.org/v1/FeedService.svc/
GET https://www.postsharp.net/nuget/packages/
Restoring packages for M:\visual studio 2015\Projects\CustomerPortal\src\CustomerPortal\project.json
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='AutoMapper'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.nuget.org/api/v2/FindPackagesById()?id='AutoMapper'
GET https://www.nuget.org/api/v2/FindPackagesById()?id='System.Collections.Immutable'
GET http://packages.nuget.org/v1/FeedService.svc/FindPackagesById()?id='System.Collections.Immutable'
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='System.Collections.Immutable'
Warning: FindPackagesById: AutoMapper
An error occurred while sending the request.
GET https://www.postsharp.net/nuget/packages/FindPackagesById()?id='AutoMapper'
Warning: FindPackagesById: AutoMapper
Response status code does not indicate success: 407 (Proxy Authentication Required).
Update
I've managed to capture a non-working request (returning 407) and a working request with the only difference being the content of the Proxy-Authorization header which is longer. This would suggest the proxy authentication does exist but it's using a different protocol.
I had the same problem a few weeks ago. For me it has helped to put in the the following in the machine.config (Windows/Microsoft.NET/Framework64/v4.0.30319/Config)
<system.net>
<settings>
<ipv6 enabled="True"/>
</settings>
<defaultProxy useDefaultCredentials="True" enabled="True">
<proxy proxyaddress="http://your.proxyserver.ip:port"/>
</defaultProxy>
</system.net>
I had to modify the 32 bit machine.config (assumption being VS runs in 32 bit) to add the <system.net> section but omitting anything within the <defaultProxy> tag:
<system.net>
<defaultProxy useDefaultCredentials="True" enabled="True" />
</system.net>
According to MSDN:
If the defaultProxy element is empty, the proxy settings from Internet Explorer will be used.
This is perfect for me as every other application on my machine works - including IE.
manchine.config location (Win 7): %SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
Note
I resolved this thanks to #user3063127 pointing me in the right direction (you have an upvote). As far as I can tell this only affects package restore on DNX projects and may well be fixed when RC2 is released.
Updated to latest nuget.exe 1st
nuget update self
Added proxy details to the config file:
nuget config -Set http_proxy=http://username:password#proxyserver.company.com:port
You need to modify file 2 .config files:
for Visual Studio 2015
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe.config
for Visual Studio 2017
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\vsn.exe.config
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe.config
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy usesystemdefault="True" bypassonlocal="True" proxyaddress="http://yourproxy:proxyport" />
<bypasslist>
<add address="(.*\.)?anyotherdomain\.com?(.*)" />
<add address="(.*\.)?nuget\.org?(.*)" />
<add address="192\.168\.\d{1,3}\.\d{1,3}" />
</bypasslist>
</defaultProxy>
<settings>
<ipv6 enabled="false"/>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
The bypass for nuget.org will work if, without the proxy, you still can get it's IP from DNS server and nothing else is blocking it.
Also need this to install nuget
Open the file C:\Users\[YOUR_USER_NAME]\AppData\Roaming\NuGet\NuGet.Config and add inside the <configuration> <\configuration> tag the following:
<config>
<add key="http_proxy" value="http://yourproxy:proxyport" />
</config>
Taken from Marco Mengoli's Blog
If you have Fiddler installed, tick the option 'Automatically Authenticate' under the Rules option, should fix the above issue.
Selecting the Automatically Authenticate
Got this from the following post
Configuring Fiddler to use company network's proxy?
If you don't know the proxy server details, you can go with other workaround to overcome this error "407 (Proxy Authorisation Required.)"
Workaround:
1. Download/Install Fiddler
2. Click Menu Rules -> Automatically Authenticate
Without closing Fiddler, now try to do restore package in Visual Studio. It should now restore the packages without any proxy error.
This is not a neat solution, but still an alternate workaround to resolve this issue. This solution tries to utilise Fiddler as Proxy.
Maybe you have wrong proxy credentials in Credential Manager. Try to remove it.
Control Panel -> User Account -> Credential Manager.
Remove proxy credentials resolved my problem.
Adding proxy username, password fixed my 407 authentication issue.
Place the following snippet in NuGet.config file located at C:\Users\myUserName\AppData\Roaming
<configuration>
<config>
<add key="http_proxy" value="http://my.proxy.address:port" />
<add key="http_proxy.user" value="mydomain\myUserName" />
<add key="http_proxy.password" value="[base64 encoded Password]" />
</config>
</configuration>
Ref: https://forums.asp.net/t/2096179.aspx?Proxy+407+Access+Denied
I am creating Datadriven Unit(MS Unit Test) Test using Excel(*.xlsx) file as data source.
it is erroring out with the following error
Result Message: The unit test adapter failed to connect to the data
source or to read the data. For more information on troubleshooting
this error, see "Troubleshooting Data-Driven Unit Tests"
(http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.
Error details: ERROR [IM014] [Microsoft][ODBC Driver Manager] The
specified DSN contains an architecture mismatch between the Driver and
Application
I have set the Copy to Output directory : always for the DateRangeTest.xlsx
I also tried defaultdir=.\;, defaultdir=.;, and defaultdir=c:\projectName\bin\debug\;
Here is the section from app.config
<configSections>
<section
name="microsoft.visualstudio.testtools"
type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
</configSections>
<connectionStrings>
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
</connectionStrings>
<microsoft.visualstudio.testtools>
<dataSources>
<add name="DateRangeTestDataSource"
connectionString="DateRangeConstr"
dataTableName="Sheet1$"
dataAccessMethod="Sequential"/>
</dataSources>
</microsoft.visualstudio.testtools>
There are (2) options here - you can either remove the DSN requirement or install the opposite Excel/Access runtime bitness of the Office product you have installed.
Option 1 - remove DSN from Connection String
Change from this:
<add name="DateRangeConstr"
connectionString="Dsn=Excel Files;dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
To this:
<add name="DateRangeConstr"
connectionString="dbq=DateRangeTest.xlsx;defaultdir=.\; driverid=790;maxbuffersize=2048;pagetimeout=5"
providerName="System.Data.Odbc" />
Option 2 - Install ODBC Drivers for Opposite Bitness
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x86 (AccessDatabaseEngine.exe)
For Office x64, install Microsoft Access Database Engine 2010 Redistributable for x64 (AccessDatabaseEngine_x64.exe).
This fix should be the same whether you have Office 2010 or Office 2013.
To test this change - you should be able to configure the Excel Files DSN for both x86 and x64 once installed.
32-bit ODBC: %WINDIR%\SysWOW64\odbcad32.exe
64-bit ODBC: %WINDIR%\System32\odbcad32.exe
Click on "Excel Files" and then click "Configure" and you should see a dialog. If an error occurs when you click "Configure" - you don't have the proper office driver installed for that bitness.
We need not to install anything to our system to run the external excel data driven unit tests.
We need to simply run the Data Source Wizard present under Visual Studio Data Source Explorer.
Watch this video. This Tutorial tells how to run Data Driven (Parameters) unit tests using Visual Studio Testing Tools.
VS keeps crashing, usually when I want to click on some text I want to edit.
When I look in the event log I get;
Log Name: Application
Source: Application Error
Date: 26/03/2013 15:18:30
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: (removed)
Description:
Faulting application name: devenv.exe, version: 10.0.40219.1, time stamp: 0x4d5f2a73
Faulting module name: clr.dll, version: 4.0.30319.269, time stamp: 0x4ee9ae83
Exception code: 0xc00000fd
Fault offset: 0x00194a5d
Faulting process id: 0x47c
Faulting application start time: 0x01ce2a3396f0faf2
Faulting application path: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 69d0daee-9628-11e2-aeba-005056c00008
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-03-26T15:18:30.000000000Z" />
<EventRecordID>23553</EventRecordID>
<Channel>Application</Channel>
<Computer>(removed)</Computer>
<Security />
</System>
<EventData>
<Data>devenv.exe</Data>
<Data>10.0.40219.1</Data>
<Data>4d5f2a73</Data>
<Data>clr.dll</Data>
<Data>4.0.30319.269</Data>
<Data>4ee9ae83</Data>
<Data>c00000fd</Data>
<Data>00194a5d</Data>
<Data>47c</Data>
<Data>01ce2a3396f0faf2</Data>
<Data>c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe</Data>
<Data>C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll</Data>
<Data>69d0daee-9628-11e2-aeba-005056c00008</Data>
</EventData>
</Event>
also I get this;
Log Name: Application
Source: Windows Error Reporting
Date: 26/03/2013 15:21:01
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: (removed)
Description:
Fault bucket 2985755835, type 1
Event Name: APPCRASH
Response: Not available
Cab Id: -721041670
Problem signature:
P1: devenv.exe
P2: 10.0.40219.1
P3: 4d5f2a73
P4: clr.dll
P5: 4.0.30319.269
P6: 4ee9ae83
P7: c00000fd
P8: 00194a5d
P9:
P10:
Attached files:
C:\Users\xxx\AppData\Local\Temp\WERE350.tmp.WERInternalMetadata.xml
C:\Users\xxx\AppData\Local\Temp\WERF0C9.tmp.appcompat.txt
C:\Users\xxx\AppData\Local\Temp\WERF108.tmp.mdmp
These files may be available here:
C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_devenv.exe_3f453f47c0d86c534010e7cf6788bb8f42fbcd_cab_144e2fda
Analysis symbol:
Rechecking for solution: 0
Report Id: 69d0daee-9628-11e2-aeba-005056c00008
Report Status: 8
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2013-03-26T15:21:01.000000000Z" />
<EventRecordID>23554</EventRecordID>
<Channel>Application</Channel>
<Computer>(removed)</Computer>
<Security />
</System>
<EventData>
<Data>2985755835</Data>
<Data>1</Data>
<Data>APPCRASH</Data>
<Data>Not available</Data>
<Data>-721041670</Data>
<Data>devenv.exe</Data>
<Data>10.0.40219.1</Data>
<Data>4d5f2a73</Data>
<Data>clr.dll</Data>
<Data>4.0.30319.269</Data>
<Data>4ee9ae83</Data>
<Data>c00000fd</Data>
<Data>00194a5d</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
C:\Users\xxx\AppData\Local\Temp\WERE350.tmp.WERInternalMetadata.xml
C:\Users\xxx\AppData\Local\Temp\WERF0C9.tmp.appcompat.txt
C:\Users\xxx\AppData\Local\Temp\WERF108.tmp.mdmp</Data>
<Data>C:\Users\xxx\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_devenv.exe_3f453f47c0d86c534010e7cf6788bb8f42fbcd_cab_144e2fda</Data>
<Data>
</Data>
<Data>0</Data>
<Data>69d0daee-9628-11e2-aeba-005056c00008</Data>
<Data>8</Data>
</EventData>
</Event>
Standard checks to resolve these types of errors:
uninstall any beta/ctp releases for Visual Studio.
look in the Windows Event Viewer and check for the following two items in the Application log: it will contain a stacktrace which may help you find the culprit.
delete any *.*user files and the solution user options file (.suo)
Run visual studio with activity logging turned on to see if the logs contain a hint to what's causing the crash. (devenv /log)
Run Visual Studio in Safe mode (devenv /safemode)
Clear the ComponentModelCache folder
Check to see if any extensions/add-ons/plugins need updates and update them first to see if that fixes your problem.
disable all add-ins and extensions (VS Commands, WebEssentials etc)
uninstall all plugins (resharper, coderush, reflector etc)
install the latest patches and service packs, you may need to re-apply these servicepacks if you've installed SQL Server or another product that installs a feature which is based on Visual Studio Shell:
2005: SP 1 & TFS 2010 Forward Compatibiltiy Patch & Visual Studio update for Windows Vista
2008: SP 1 & TFS 2012/VSO Forward Compatibiltiy Patch
2010: SP 1 & TFS 2012/VSO Forward Compatibility Patch & Visual Studio update for Windows 8 and TFS 2012.
2012: Update 5
2013: Update 5
2015: Update 3 & KB3165756
2017: Update to the latest version
reset vs settings (devenv /resetsetting /resetaddin /resetskippkgs /setup)
backup & remove the %LOCALAPPDATA%\Microsoft\VisualStudio\ folder to have Visual Studio recreate your setting folder.
Do not run Visual Studio while installing extensions, updates etc.
Try to reproduce it. If it still occurs, repair Visual Studio and reapply the latest service packs and hotfixes in order. If it then still occurs, submit a support ticket to Microsoft, or an item on connect.
If it doesn't occur turn-on/install/restore the items one by one until you can find the culprit. I know it's a lot of work, but since your error happens somewhere deep inside the CLR (you're seeing a StackOverflow Exception), it's hard to pinpoint the problem easily. When you've found the problematic item, see if there is an update for it or request their support (or update your question).
In the worst case you can perform a force-uninstall of Visual Studio using vs_setup /uninstall /force, that should work on the 2012 and newer installers.
If you're still on an old version of Visual Studio (2010 or older), really, really. really consider upgrading. These versions are past their support lifetime and were built for versions of Windows that are not even supported anymore. I know the pain these upgrades can cause in the short term, but the long-term solution is really to move away from the old versions.
A quick and dirty approach is to rename your %LOCALAPPDATA%\Microsoft\VisualStudio\ folder to VisualStudio.backup\ and restart devenv. It will recreate the folder and populate it with default settings files. You will lose any customizations of course, but many times that is ok and/or easily recreated. You always have the backup folder just in case.
If you want to take it a step further, you can move settings one-by-one from the backup back into the new folder until you can completely isolate the problem.
None of the above worked. But I saw a user settings file had appeared next to the .sln file. I deleted it, and the solution's corresponding .suo file. This fixed the problem.
I'm creating an installer for one of our products. The installer was done with WISE earlier but we wanted to change this to wix with this release. It's important that our users uninstall the old version of the product before installing the new version and thus I need to check for a key in the registry that was created by the old installer (the key is removed when the old version is uninstalled).
I have a conditional check in the wxs like so:
<!-- Check if older version of Product has been installed. Must be removed by user-->
<!-- The key below is set by the old installer. If it exists, the old version is there.-->
<Property Id="OLDKEY">
<RegistrySearch Id="OldRegKey" Root="HKLM" Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Company Product för Product" Name="DisplayName" Type="raw"></RegistrySearch>
</Property>
<Condition Message="You need to uninstall the old version of Product before installing this one.">
OLDKEY
</Condition>
You'll notice a Swedish character in there. I suspect this might be the cause of some problems. This is how I configured since I had to handle Swedish characters:
<Product
Id="*"
Name="$(var.Manufacturer) $(var.ApplicationName)"
Language="1033"
Version="!(bind.FileVersion.Product.exe)"
Manufacturer="$(var.Manufacturer) AB"
UpgradeCode="[GUID]"
Codepage="1252"
>
Notice the 1252 codepage.
When I install and have the old version on the machine, I find the key in the registry and the installer will show me the message. If I remove the old version I can see the registry key disappear but the installer will still show me the message and exit. I have tried rebooting (you never know) to no avail.
I'm running out of ideas... any thoughts?
Turns out the registry search returns 1 if key is not found. So I changed
OLDKEY
To
<![CDATA[OLDKEY <> 1]]>
And it was fixed.