I've been working on a project for some time now and now I want to use Visual Studio Team Services for it. Locally, the building in Visual Studio doesn't give an error and the application works as intended.
I've checked in this working code to VSTS so it's in the repo and good to go.
Now I want to build it. I created a new Build definition with nothing changed. When I run the build it fails. I tried editing the build definition but with my 0 experience with this I only screw up more and create more errors.
My problem: Apparently, it wants to find C:\a\1\s But I have no idea why and how it came up with that path.
What do I have to change in the build definition? I'm new to this so I don't know what all the settings do and where the files are that it needs.
I tried adding the .sln file from the project folder to the build definition (as shown in the 2nd image) but it still want to find that weird path.
So here are the build definitions, steps that go wrong and the errors in the logs.
NuGet restore ***.sln
2016-03-07T10:28:15.8302718Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:28:15.9337363Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:28:16.5636975Z ##[error]Could not find a part of the path 'C:\a\1\s'.
2016-03-07T10:28:16.5876990Z ##[error]No solution was found using search pattern 'C:\a\1\s\**\*.sln'.
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:28:16.6827013Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:28:17.1800860Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1810857Z ##[debug]system.culture=en-US
2016-03-07T10:28:17.1820859Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:28:17.1820859Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1820859Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:28:17.1830859Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:28:17.1830859Z ##[debug]check path : C:\a\1\s
2016-03-07T10:28:17.1840858Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:28:17.1840858Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:28:17.1850860Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:28:17.1860857Z ##[debug]task result: Failed
NuGet restore $/Test project/QRM/QRM.sln
2016-03-07T10:47:46.0629142Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18
2016-03-07T10:47:46.1969152Z Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\NuGetInstaller\0.1.18\NuGetInstaller.ps1
2016-03-07T10:47:46.8519190Z ##[error]Cannot find path 'C:\a\1\s\QRM\QRM.sln' because it does not exist.
2016-03-07T10:47:46.8639180Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\agent\worker\tools\NuGet.exe restore "C:\a\1\s\QRM\QRM.sln" -NonInteractive
2016-03-07T10:47:48.8829320Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2016-03-07T10:47:48.8999324Z ##[error]Could not find a part of the path 'C:\a\1\s\QRM\QRM.sln'.
2016-03-07T10:47:48.9249320Z ##[error]Unexpected exit code 1 returned from tool NuGet.exe
Copy Files to: $(build.artifactstagingdirectory)
2016-03-07T10:47:49.0239330Z Set workingFolder to default: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11
2016-03-07T10:47:49.6659427Z ##[debug]check path : C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6779370Z Not found SourceFolder: C:\a\1\s
2016-03-07T10:47:49.6789372Z ##[debug]set resource file to: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6799369Z ##[debug]system.culture=en-US
2016-03-07T10:47:49.6799369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\task.json
2016-03-07T10:47:49.6809368Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6809368Z ##[debug]Contents=**\bin\release\**
2016-03-07T10:47:49.6809368Z ##[debug]SourceFolder=C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]check path : C:\a\1\s
2016-03-07T10:47:49.6819369Z ##[debug]load strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\lib.json
2016-03-07T10:47:49.6829365Z ##[debug]load loc strings from: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\CopyFiles\1.0.11\node_modules\vsts-task-lib\strings\resources.resjson\en-US\resources.resjson
2016-03-07T10:47:49.6829365Z ##[debug]task result: Failed
Edit
The build definition's repository tab:
The repository structure:
According to the logs you provided:
2016-03-07T15:00:44.4590685Z Done syncing repository Test project to version 3 (workspace version -1)
This issue may caused by the access permission of your build account. Please check and make sure the account that the build agent use has the permission to access to your code repository.
Same issues for your reference:
TFS 2105 build issue
TFS 2015 Build Agent failing syncing the repository
When you queued a new build, did you enter a Source Version to get? I see a Version 3 coming by in the logs, but no files are actually transferred. If you want to fetch a specific changeset, you need to enter C3 instead of 3. But I'd recommend to just leave the box empty.
Related
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I'm new to the subject of windows drivers. I'm trying to build one of the Windows-driver-samples in Visual Studio 2015. The compilation and linking steps pass without errors and then I get the following error:
TRACKER : error TRK0002: Failed to execute command:
""C:\Program Files (x86)\Windows Kits\10\bin\x86\inf2cat.exe"
/os:10_x64 /driver:x64\Debug\WFPSamplerCalloutDriver\".
The operation identifier is not valid.
(Note the relative path in /driver argument). If I call Inf2Cat manually from command prompt with full path to the driver, it passes without a hitch:
C:\Program Files (x86)\Windows Kits\10\bin\x86>Inf2Cat.exe /os:10_x64
/driver:C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug\W
FPSamplerCalloutDriver
...........................
Signability test complete.
Errors:
None
Warnings:
None
Catalog generation complete.
C:\Users\****\Windows-driver-samples\network\trans\WFPSampler\sys\x64\Debug
\WFPSamplerCalloutDriver\wfpsamplercalloutdriver.cat
So, it seems to me that VS somehow failed to provide the full path to the driver in the argument to Inf2Cat.
How can I fix this? Which configuration property of my project is incorrect?
Description
Seems Inf2Cat from SDK10 does not accept directory path format provided by VS Project Configurator. Works when: either output folder name has with no trailing "\" or folder name ends up with "\.".
Workaroud
Disable Inf2Cat under Project Preferences: Run Inf2Cat -> No
Configure build events under Build-Events->Post Build-Event: Command Line -> "$(WindowsSdkDir)bin\$(DDKPlatform)\inf2cat.exe" /os:10_$(DDKPlatform) /driver:"$(ProjectDir)$(IntDir)$(MSBuildProjectName)"
I'm trying to run Nunit unit tests using finalbuilder/continua and it's simply not working and I don't know why. I just get this error:
No testable files found. Check that you have entered valid paths for
the Files field. Also ensure that the Workspace and Repository Rules
are set up correctly to copy the files to the agent.
I have the following configuration:
I'm building the dll before hand:
I can see the dll in (what I think is) the right directory:
I turned on verbose logging but it's not helpful. I just get the same information again:
Medium: 08:52:38.824 {T12} [Debug] Running action 'NUnit MES_Helpers_Test (NUnitAction)'.
Medium: 08:52:38.840 {T12} [Execute Action] Action 'NUnit MES_Helpers_Test' has failed due to an error: No testable files found. Check that you have entered valid paths for the Files field. Also ensure that the Workspace and Repository Rules are set up correctly to copy the files to the agent.
Medium: 08:52:38.840 {T12} [Debug] Running action 'Build solution (MSBuildAction)'.
what am I missing here?
There appears to be an 's' missing from your file path.
Change:
$Workspace$\Output\MES_Helpers_Test\MES_Helpers_Test.dll
to
$Workspace$\Output\MES_Helpers_Test\MES_Helpers_Tests.dll
Basically, I need to invoke msbuild three times in succession. Each of the three builds needs to be scanned. The first one is OK, but the 2nd and 3rd fail because the scanner is unable to clean the .sonarqube directory.
I get "Access to the path 'SonarQube.Common.dll' is denied.
It appears that the .dll is still in use, even though I put a 60 second delay between the builds.
Here is a snippet of the output:
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe begin /k:com.carestream.SteveK_Backend /n:SteveK_Backend /v:1.0 /s:C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
SonarQube Scanner for MSBuild 3.0.2
Loading analysis properties from C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
sonar.verbose=true was specified - setting the log verbosity to 'Debug'
Pre-processing started.
Preparing working directories...
Using environment variables to determine the download directory...
Removing the existing directory: C:\home\repos\SteveKTemp\.sonarqube
Creating directory: C:\home\repos\SteveKTemp\.sonarqube
12:50:27.707 12:50:27.703 Loading analysis properties from C:\home\repos\SteveKTemp\src\Backend_Sonar_Properties.xml
12:50:27.707 12:50:27.707 sonar.verbose=true was specified - setting the log verbosity to 'Debug'
12:50:27.708 Updating build integration targets...
12:50:27.709 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\15.0\Microsoft.Common.targets\ImportBefore
12:50:27.709 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\14.0\Microsoft.Common.targets\ImportBefore
12:50:27.71 The file SonarQube.Integration.ImportBefore.targets is up to date at C:\Users\rocbuilder\AppData\Local\Microsoft\MSBuild\12.0\Microsoft.Common.targets\ImportBefore
12:50:27.711 Installed SonarQube.Integration.targets to C:\home\repos\SteveKTemp\.sonarqube\bin\targets
12:50:27.712 Creating config and output folders...
...
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe end
SonarQube Scanner for MSBuild 3.0.2
Default properties file was found at C:\SonarQube\Scanners\sonar-scanner-msbuild-3.0.2.656\SonarQube.Analysis.xml
Loading analysis properties from C:\SonarQube\Scanners\sonar-scanner-msbuild-3.0.2.656\SonarQube.Analysis.xml
Post-processing started.
12:52:04.002 Loading the SonarQube analysis config from C:\home\repos\SteveKTemp\.sonarqube\conf\SonarQubeAnalysisConfig.xml
12:52:04.003 Not running under TeamBuild
12:52:04.004 Analysis base directory: C:\home\repos\SteveKTemp\.sonarqube
Build directory:
Bin directory: C:\home\repos\SteveKTemp\.sonarqube\bin
Config directory: C:\home\repos\SteveKTemp\.sonarqube\conf
Output directory: C:\home\repos\SteveKTemp\.sonarqube\out
Config file: C:\home\repos\SteveKTemp\.sonarqube\conf\SonarQubeAnalysisConfig.xml
...
:: CAUSE A DELAY BETWEEN 1st and 2nd Scan
C:\home\repos\SteveKTemp>PING localhost -n61 1>NUL
C:\home\repos\SteveKTemp>SonarQube.Scanner.MSBuild.exe begin /k:com.carestream.SteveK_WebCSharp /n:SteveK_WebCSharp /v:1.0 /s:C:\home\repos\SteveKTemp\src\Web_Sonar_Properties.xml
SonarQube Scanner for MSBuild 3.0.2
Loading analysis properties from C:\home\repos\SteveKTemp\src\Web_Sonar_Properties.xml
sonar.verbose=true was specified - setting the log verbosity to 'Debug'
Pre-processing started.
Preparing working directories...
Using environment variables to determine the download directory...
Removing the existing directory: C:\home\repos\SteveKTemp\.sonarqube
Failed to create an empty directory 'C:\home\repos\SteveKTemp\.sonarqube'. Please check that there are no open or read-only files in the directory and that you have the necessary read/write permissions.
Detailed error message: Access to the path 'SonarQube.Common.dll' is denied.
Pre-processing failed. Exit code: 1
I would greatly appreciate any help in finding a way to get around this problem.
Thank you.
I see there is an additional option they recommend when running multiple builds in succession.
pass /nodereuse:false to msbuild
See troubleshooting:
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+MSBuild
I have created a solution using Visual Studio 2017 which consists of a Windows Service C# Project and an InstallShield 2016 Basic MSI Project.
The InstallShield project has a single component added. This component has a number of files added using the Component->Files->Add File... (below)
Note the use of VSSolutionFolder.
Now when I open the InstallShield project (.ism) using InstallShield 2016, and build the project, I get the following build errors:
Loading File table
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config"
Building MsiFileHash table
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
Adding instance transforms to substorage...
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.exe'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.exe.config'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.pdb'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\App.config'
In Media Path Variables, there is a VSSolutionFolder with a value UNDEFINED.
I cannot change this Current Value - the UI does not allow it. Defined Value cannot be changed and Test Value doesn't seem to do much.
I have the project saved as xml but I only see the VSSolutionFolder referenced in file paths like so:
<row>
<td>acmecorp.app.service.exe</td>
<td>ACMECorpServiceFilesComponent</td>
<td>ACMECO~1.EXE|ACMECorp.App.Service.exe</td>
<td>0</td>
<td/>
<td/>
<td/>
<td>1</td>
<td><VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe</td>
<td>1</td>
<td/>
</row>
Is there a way of setting VSSolutionFolder in InstallShield? Or is there some way of fixing this.
Ideally I want it to just load in Visual Studio and InstallShield without having to muck about with source locations - yes I can remove the files and re-add, but that is not the question (if I had a larger solution it wouldn't be acceptable I don't think).
Personally I recommend keeping your application code and your installer code in two different solutions. There are several reasons including:
1) A new version of VS comes out that IS doesn't support yet and you don't want to be held back.
2) Simplifies project dependencies and build order relationships. Build your app code first then build your installer code second.
3) Depending on where you are in the agile/devops spectrum you might want to keep your peanut butter and chocolate separate.
In this scenario I use postbuild xcopy commands and msbuild publish profiles to stage my application code to a "Deploy" directory in the workspace in the directory that your .ISPROJ and .ISM lives. From there InstallShield simply uses the standard ISPROJECTDIR path variable reference. Now you don't have to deal with the complexities of project output references. You have a nice model defined of what your deployed application should look like.
Try overriding the path variable. You can do this either with external approaches like iscmdbld -L... or with the Release Configuration property Path Variable Overrides. (Note that building the solution with MSBuild should already just work.)
If there are problems overriding VSSolutionFolder itself, you can change your file links to use a new standard variable that is defined to use <VSSolutionFolder> as its default path, but will definitely allow you to override it.