I'm using Vs2010 and Wix 3.6.0917.0, for the record. I use the $(SolutionDir) property quite a bit in my .wixproj file, since I only ever build the installer as part of a solution build or as part of a team build, and never by itself. However, while building from the command line works just fine (both from cmd on the desktop and when building on build agents), when I attempt to reload the .wixproj file into the IDE, I get errors because all the $(SolutionDir) variables are resolving to the project directory, not the solution directory. Consider:
C:\workspace\projectCollection\teamProject\branch\solution.sln
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
and assume a shared custom targets file:
C:\workspace\projectCollection\teamProject\branch\build\shared.targets
which is referenced inside installer.wixproj with:
<Import Project="$(SolutionDir)build\shared.targets">
Command line builds work fine...
C:\workspace\projectCollection\teamProject\branch\> MSBuild /t:build /property:Platform=x64;Configuration=Debug solution.sln
0 Errors
0 Warnings
Build succeeded!
But load into vs2010 and you see...
The imported project
"C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj
You can see here that the resolved result of $(SolutionDir)build\shared.targets is getting the project directory and not the solution directory. What gives?
My guess would be that $(SolutionDir) resolves to nothing when the wixproj is being loaded into VS2010. In this case the imported file becomes "build\shared.targets". Since the path is relative it is assumed to be relative to the project directory. Using ".." or some other path could get you around the problem.
I verified this failed with WiX 3.5.2222.0 in VS2010. A C# console application project (csproj) worked as expected.
Have you filed a bug against WiX for this?
I looked at the WiX vs2010 addin code a little bit and the Solution properties are only created when doing a build and not when the project is loaded.
Related
I have a Visual Studio 2019 solution that I inherited from someone else with multiple projects.
I'm trying to build one of the projects in particular.
I have a reference to an external assembly with "copy local" set to true.
When I build my project, my referenced assembly gets copied over tot he output folder but then it gets deleted.
I know it gets copied because I have tried using the post build event "dir $(TargetDir)" and it shows the dll.
Any idea why it would get deleted afterward?
The problem was caused by by these lines in my csproj file:
<Target AfterTargets="AfterBuild;NonWinFodyTarget" Name="CleanReferenceCopyLocalPaths">
<Delete Files="#(ReferenceCopyLocalPaths->'$(OutDir)%(DestinationSubDirectory)%(Filename)%(Extension)')" />
</Target>
The solution was using Fody to weave the assemblies.
I had removed the weaving, but this line in the csproj file was a left over from the use of Fody.
The issue is that you have used some nuget packages like Costura.Fody which could merge your specific external assembly into the main output file while it is set to Copy Local True.
So please check if your FodyWeavers.xml file has any merge operation of your external assembly.
In my side, I have an external assembly called ClassLibrary22.dll and set it to CopyLocal to true.
And add these on FodyWeavers.xml file:
So the assembly ClassLibrary22.dll will be merged into the main project exe or dll output file and did not exist under output folder.
That is the cause.
I have Visual studio project solution which has multiple .csproj. Each .csproj has some reference libraries.The project settings are made in such a way the reference libraries are built first and then .csproj is built. This works as expected when i run it in visual studio IDE. But when i try to execute using msbuild i'm getting an error saying target doesn't exist. Gone through many posts related to this issue ,tried possible things.But didn't built.Looks like i might be doing something silly or missing something in the settings.
Also tried using devenv from commandline. With this option i dont see any error but at same time the project doesnt build.I dont see any message after execution of command.Im using visual studio 2015
Here is my project structure
Poject.sln
ProjectA
porjectB
projectC
Libraries
libA
libB
msbuild "project.sln" target:"D:\Projects\Source\Demo\ProjectA\ProjectA.csproj" /t:build
"/p:Configuration=Debug" "/p:platform=x86"
I see the below error
"D:\project.sln" (D:\Projects\Source\Demo\ProjectA\;build target) (1) ->
D:\project.sln.metaproj : error MSB4057: The target "D:\Projects\Source\Demo\ProjectA" does not exist in the project. [D:\project.sln]
Here is the command used using devenv
devenv.exe "project.sln" /build Debug /project `"D:\Projects\source\Demo\Applications\ProjectA\ProjectA.csproj" /projectconfig Debug
After executing the above its doesnt build and i dont see any error too.
error MSB4057: The target "D:\Projects\Source\Demo\ProjectA" does not
exist in the project.
The error indicates your path in command is not valid and project.sln can't recognize the path. So you actually meet one path-related issue. And you should pass the ProjectA to the targets argument instead of ProjectA.csproj! More details see tip3 in For MSBuild.
For MSBuild:
1.If you're only trying to build ProjectA and its reference libraries.
Navigate(cd) to path where ProjectA.csproj exists, and then use command msbuild ProjectA.csproj /t:build /p:Configuration=Debug /p:platform=x86
Also you can directly use command msbuild AbsolutePath\ProjectA.csproj /t:build /p:Configuration=Debug /p:platform=x86. It's not necessary to use " to cover the path and arguments.
(ProjectA.csproj file should have definitions about the reference to those two library projects, so msbuild ProjectA.csproj will build those two projects first. You don't need to specify the xx.sln in your command.)
2.If you're trying to build whole solution(all the projects):
msbuild project.sln /t:build /p:Configuration=xxx /p:platform=xxx
Navigate to solution folder when you run above command, or use absolutepath\project.sln with that command.
3.When you want to build specific projects(more than one) in solution:
Check How to: Build Specific Targets in Solutions By Using MSBuild.exe. Since you're only build ProjectA, you don't need to use this format. For example: Only when you need to build both ProjectA and ProjectB, but not build ProjectC... You can use command like:
msbuild xxx.sln /t:NotInSlnfolder:Build;NewFolder\InSolutionFolder:Build
Pay attention to the path when you use this format. Whether your project is in solution folder can affect the build result a lot ! And, the direct cause of your issue, this command's targets argument needs one ProjectName as input instead of ProjectName.csproj.
For Devenv command:
1.I always use VS2017 and VS2019,so I'm not certainly sure if VS2015's devenv related command has big difference from VS2017's or VS2019's. But according to details from this VS2017 document:
Commands that begin with devenv are handled by the devenv.com utility, which delivers output through standard system streams, such as stdout and stderr.
Alternatively, commands that begin with devenv.exe can use the same switches, but the devenv.com utility is bypassed. Using devenv.exe directly prevents output from appearing on the console.
I think that's why you don't see any message after execution of command. You should use devenv.com command to see the output in console. And it's by design that devenv.exe will prevents output from appearing on the console.
2.The following command builds the project CSharpWinApp, using the Debug project build configuration within MySolution.
devenv "%USERPROFILE%\source\repos\MySolution.sln" /build Debug /project "CSharpWinApp\CSharpWinApp.csproj" /projectconfig Debug
More details about devenv reference please check this document.
In addition:
1.Looks like you have one strange project structure. I checked your error message above and it seems your several projects(xx.csproj) are not under Solution(xx.sln) folder. Just a suggestion, the normal folder structure for VS2015 is always:
Solution folder
xx.sln
ProjectA folder
ProjectA.csproj
ProjectB folder
ProjectB.csproj
2.For most of the projects, build using msbuild is more powerful and convenient than build using devenv. So if you don't have special reason, I recommend using Msbuild, the build engine of VS.
Hope all above helps to resolve your issue and puzzle. Let me know if your issue persists:)
File "/Users/morel893/Desktop/env/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "projects_project" does not exist
LINE 1: ...ct"."technology", "projects_project"."image" FROM "projects_...
When VS2017 was used to create a stateful solution, producing the standard boilerplate code, the resulting two projects have two different MSBuild versions.
The application uses MSBuild version 1.5.0.
The service uses MSBuild version 1.6.0 (the current "latest").
If I run the solution this way, it runs fine on my local Service Fabric cluster.
But when after I use NuGet to update the application's MSBuild to 1.6.0 (so both application and server projects use the same), the following errors occur.
Severity Code Description Project File Line Suppression State
Error The OutputPath property is not set for project 'gt_strd5.sfproj'. Please check to make sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' P follow a project-to-project reference to this project, this project has belatform='x64'. This error may also appear if some other project is trying toen unloaded or is not included in the solution, and the referencing project does not build using the same or an equivalent Configuration or Platform. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 737
Severity Code Description Project File Line Suppression State
Error MSB4057 The target "CreateManifestResourceNames" does not exist in the project. gt_strd5 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets 2630
I found that after the change, some references in the application's project file continued to reference MSBuild 1.5.0. In my case, the gt_strd5.sfproj file contained four references which needed to be updated from 1.5.0 to 1.6.0. See the snippets from the XML below.
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.props')"
.....
Import Project="..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets" Condition="Exists('..\packages\Microsoft.VisualStudio.Azure.Fabric.**MSBuild.1.5.0**\build\Microsoft.VisualStudio.Azure.Fabric.Application.targets')"
To verify this, I went back a couple times and was able to reproduce both the issue and this solution.
Hope it saves someone else some time.
Best Regards
I was getting this error into PCF control.
Run Developer Command Prompt VS2017/ VS2019
a) Remove white space from your folder like Test%20-%20PCFs (source control generated name) should be TestPCFs
b) Go to pcf project folder from cmd line & run msbuild /t:restore
b) Go to cds project folder from cmd line & run msbuild /t:restore
c) On cds project folder, run msbuild
d) For release deployment run msbuild /p:configuration=Release
For other types of projects
a) Remove white space from your folder name
b) run msbuild /t:restore
c) run msbuild
I installed the VS2010 web publishing updates yesterday, and now whenever I try to load a WiX setup project (all showing as unloaded in solution explorer) I'm getting the error:
The imported project "PROJECTNAME.wpp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.5\Web\Microsoft.Web.Publishing.targets
Where PROJECTNAME is the path to my setup wixproj file, without the .wixproj extension. I've checked through the project file and there is no reference to a wpp.targets file anywhere. I decided to try and create a blank targets file in that location and so added one with just this in it:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
But got exactly the same error - a not found exception despite the file being there!
I then dug into the Microsoft.Web.Publishing.targets file and had a look for any ".wpp.targets" text, which gave me this:
<PropertyGroup Condition="'$(EnableWebPublishProfileFile)'=='true' And
'$(WebPublishProfileFile)' != '' And Exists($(WebPublishProfileFile)) ">
<WebPublishProfileCustomizeTargetFile Condition="'$(WebPublishProfileCustomizeTargetFile)'==''">
$([System.IO.Path]::ChangeExtension($(WebPublishProfileFile), '.wpp.targets'))
</WebPublishProfileCustomizeTargetFile>
...
So that looks to be setting up a filename of PROJECTNAME.wpp.targets, but only when the EnableWebPublishProfileFile property is set to true. I added this to my wixproj file's main propertygroup:
<EnableWebPublishProfileFile>False</EnableWebPublishProfileFile>
Again though, it made no difference at all to the error. I'm running out of ideas here now!
Further update
I've been trying to repo this on a blank project (so far without success), and the messing about has narrowed the error down to this line (186) in the Microsoft.Web.Publishing.targets file:
<Import Project="$(WebPublishPipelineCustomizeTargetFile)"
Condition="'$(WebPublishPipelineCustomizeTargetFile)' != ''"/>
This is set at the top of the file:
<WebPublishPipelineCustomizeTargetFile
Condition="'$(WebPublishPipelineCustomizeTargetFile)'==''">
$(WebPublishPipelineProjectDirectory)\*.wpp.targets
</WebPublishPipelineCustomizeTargetFile>
I'm not sure how this is getting changed to PROJECTNAME.wpp.targets though?
I tried overriding this in my project file, but once again, it makes no difference at all.
Next I added an Exists() condition to the line in the targets file, now some projects are working and others are not, instead failing (on build) with the error:
The "DisableEscapeMSBuildVariable" parameter is not supported by the "ImportParametersFile" task. Verify the parameter exists on the task, and it is a settable public instance property.
My journey continues...
I experienced the same issue when trying to open a standard web project.
The proj file was referencing the following import for v10.0 targets but throwing the import error in the question which referred to v10.5 targets.
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" />
The same was true when I referenced a hard coded path - I still got v10.5 error
My solution was to simply back up and remove that version located at:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\10.5
I'm really not sure what other programs and projects need this version or why import paths were not followed but it go this project open for me seeming falling back to the correct version.
I'm about to start doing some benchmarking/testing of our builds, and I'd like to drive the whole thing from a command line. I am aware of DevEnv but am not convinced it can do what I want.
If I could have a single file built within a single project, I'd be happy.
Can this be done?
The magical incantation is as follows. Note that this has only been tested with VS 2010 - I have heard this is the first version of Visual Studio with this capability:
The Incantation
<msbuild> <project> <settings> <file>
Where
msbuild is a path to MSBuild.exe. Usually this should be set up for you by the VS2010 bat file so the right one will end up in your PATH, but if not I found one at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
project is the path to the vcxproj file within which your source file resides.
settings include the following:
/p:Configuration="Debug" // or whatever your Configuration is
/p:Platform=x64 // or x86
/t:ClCompile // to specify specifically you're looking to compile the file
file is actually another setting:
/p:SelectedFiles="path_to_file"
Notes
For <project> I had to specify a project (vcxproj) file instead of a solution (sln) file. The sln I would have used has multiple projects within it, so there would have been extra work to go that route anyhow (if it can even be done).
For the /p:Platform=x64 setting, there are several environment variables that pivot on what platform you are targeting (x64 v. x86) so make sure you set those up properly via Visual Studio's vcvarsall.bat.
Regarding path_to_file in the SelectedFiles parameter, this path must be the path as specified in the project file. If the path does not match the path used in the project file to reference the source, it doesn't seem to work.