I'm using msbuild 3.5, visual studio 2008, and web deployment projects.
I enabled webconfig replacement option for the web deployment project.
I thought I could do something like the following in the build script by appending another ItemGroup for release?
<ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<WebConfigReplacementFiles Include="webDebug.config">
<Section>connectionStrings</Section>
</WebConfigReplacementFiles>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">
<WebConfigReplacementFiles Include="webRelease.config">
<Section>connectionStrings</Section>
</WebConfigReplacementFiles>
</ItemGroup>
<Import Project
I do the following just fine:
msbuild myProject.wdproj
and whatever I have for the Include attribute, whether it be webDebug or webRelease it will work for the Debug version.
How do I do the same for the Release version?
I tried the following:
msbuild myProj.wdproj /p:Configuration=Release
but the connection string is never replaced properly.
What can I try next?
Related
I'm updating an old Visual Studio extension for VS 2017. It compiles fine from Visual Studio and msbuild in debug and release on my local computer.
This is the msbuild command line I am using:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU"
However, on the build machine (TFS Build 2010) calling msbuild.exe with the same command line it fails with this error
In order to fix this I am trying to specify VSToolsPath. I've tried various things such as altering the VSToolsPath entry in the .csproj (which seems to not be taken into account since doing this had no effect) and also passing it on the command line:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU" /p:VSToolsPath=Packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\
This causes a very strange error:
CopyFilesToOutputDirectory:
Copying file from "obj\Release\SymCop.dll" to "bin\Release\SymCop.dll".
SymCop -> H:\src\tools\VisualStudioExtensions\Main\VxCop\source\SymCop\bin\Release\SymCop.dll
Copying file from "obj\Release\SymCop.pdb" to "bin\Release\SymCop.pdb".
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\source\SymCop\SymCop.csproj" (default targets).
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\VxCop.sln" (Build target(s)) -- FAILED.
Done Building Project "H:\src\tools\VisualStudioExtensions\Main\VxCop\build.proj" (default targets) -- FAILED.
Build FAILED.
0 Warning(s)
0 Error(s)
The actual extension project isn't appearing in the log at all, and there's no, y'know, errors. But the build returns as failed, the return code is non-zero, and the vsix project seems to not be built (its output is missing)
Hopefully someone has some suggestions
Thanks
Edit:
For those reading this in the future, the problem seemed to be that there was an <Import> further down in the same file which didn't care about my update to $(VSToolsPath).
Changing that import fixed it:
<Import Project="$(SolutionDir)\packages\Microsoft.VSSDK.BuildTools.15.1.192\tools\VSSDK\Microsoft.VsSDK.targets"
/>
Visual Studio 2017 extension - VSToolsPath not working
I got the same result as you based on your scripts. After installed the NuGet package Microsoft.VSSDK.BuildTools to the project, the Microsoft.VSSDK.BuildTools.props will be imported in to project file, open the project file, you can find below Import:
<Import Project="..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props" Condition="Exists('..\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\Microsoft.VSSDK.BuildTools.props')" />
Then open this props file, you can notice below scripts snippet:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="VSSDK_NuGet_Configuration">
<ThisPackageDirectory>$(MSBuildThisFileDirectory)..\</ThisPackageDirectory>
<VSToolsPath>$(ThisPackageDirectory)\tools</VSToolsPath>
<VsSDKInstall>$(VSToolsPath)\VSSDK</VsSDKInstall>
<VsSDKIncludes>$(VsSDKInstall)\inc</VsSDKIncludes>
<VsSDKToolsPath>$(VsSDKInstall)\bin</VsSDKToolsPath>
</PropertyGroup>
</Project>
In this case, NuGet package override the value VSToolsPath with $(ThisPackageDirectory)\tools. So MSBuild will skip set the value setting in the next step in the project file:
<PropertyGroup>
<MinimumVisualStudioVersion>15.0</MinimumVisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<NuGetPackageImportStamp>
</NuGetPackageImportStamp>
</PropertyGroup>
Because NuGet have already set the value $(VSToolsPath), the value of Condition="'$(VSToolsPath)' == ''" would be False. In addition, you can add a target to check if the value is set, like:
<Target Name="CheckVSToolsPath" BeforeTargets="Build">
<Message Text="$(VSToolsPath)"></Message>
</Target>
You will find this value is set to:
C:\Users\Admin\Documents\Visual Studio 2017\Projects\VSIXProject2\packages\Microsoft.VSSDK.BuildTools.15.1.192\build\..\\tools
Summary above, the value of VSToolsPath was imported correctly, we do not need to passing it on the command line.
After in-depth investigation, I found the reason for the previous error "MSB4226: The imported project "(...)\VSSDK\Microsoft.VsSDK.targets" was not found." is that the MSBuild property of "VisualStudioVersion" not be set on the build server.
See below link for detail info Building a VSIX extension with the Visual Studio 2017 Build Tools:
something that a machine with the full Visual Studio 2017 does and that a machine with the Build Tools 2017 does if you open a developer command prompt. Since I was not using it, I passed it as a parameter to the MSBuild script. It can be defined too inside the .csproj file, something that previous Visual Studio versions did automatically but recent versions don’t.
So to resolve the error "MSBuild4226", you should pass the visual studio version on command line:
msbuild VxCop.sln /p:ToolsHome=C:\ProgramData\chocolatey\bin /p:Configuration=Release /p:Platform="Any CPU" /p:VisualStudioVersion=15.0
After using this command line, the error MSBuild 4226 was resolved.
Hope this helps.
I resolved this problem in VS 2019 by https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#generatepathproperty
<ItemGroup>
<PackageReference Include="Microsoft.VSSDK.BuildTools" Version="16.10.1055">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
<Import Project="$(PkgMicrosoft_VSSDK_BuildTools)\tools\vssdk\Microsoft.VsSDK.targets" />
I have build chains in TeamCity, where the dependent artifact is copied to /bin directory of the main project. The project file references the artifact. That all works.
What I want is to allow a project file include, instead of the binary reference, when building/debugging from Visual Studio. I have tried some approaches, such as using conditionals in the project file, but is there a nice clean way to approach this?
May be there is the part of solution.
May way of using several referencing types of projs.
<ItemGroup Condition=" '$(ReferencedDACPAC)' == '' ">
<ProjectReference Include="..\OmniUS\OmniUS.sqlproj">
<Name>OmniUS</Name>
<Project>{26075a62-f6b0-40c3-baa2-b9a9829da3c4}</Project>
<Private>False</Private>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ProjectReference>
<ProjectReference Include="..\OmniUS_Finance_Jural\OmniUS_Finance_Jural.sqlproj">
<Name>OmniUS_Finance_Jural</Name>
<Project>{c8b0aee7-c2a4-4370-8451-13b455bb5363}</Project>
<Private>False</Private>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ProjectReference>
</ItemGroup>
<ItemGroup Condition=" '$(ReferencedDACPAC)' == 'true' ">
<ArtifactReference Include="..\DacPacs\OmniUS.sqlproj.dacpac">
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
<ArtifactReference Include="..\DacPacs\OmniUS_Finance_Jural.sqlproj.dacpac">
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
</ItemGroup>
When I build in TeamCity, I send ReferencedDACPAC as the "System" variable in the build, and thus refer to "ArtifactReference". When i build in VisualStudio, there is no var and the referencing occurs as "ProjectReference".
I have an ASP.NET Core project that builds properly with VS but fails with TeamCity.
It is a project that compiles to a library, but TeamCity tries to build it as an executable, and complains about the lack of 'main':
CSC error CS5001: Program does not contain a static 'Main' method suitable for an entry point
The content of the .csproj file are as follow:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup Label="Configuration" Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<OutputType>Library</OutputType>
</PropertyGroup>
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
<RuntimeIdentifier>win7-x86</RuntimeIdentifier>
<OutputTypeEx>library</OutputTypeEx>
<StartupObject />
<AssemblyName>Test</AssemblyName>
<RootNamespace>Test</RootNamespace>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.2" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.3" />
<PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
</ItemGroup>
</Project>
Visual studio has no problem building the dll file.
To reproduce:
Create an ASP.NET Core (.NET Framework) project
Change the output type to library
Remove the program.cs / startup.cs files
Compile with Visual Studio to confirm a library is being built
Build with Team City and an error will appear
To avoid that error, Please look into this SO post or this
You should be using the dotnet core plugin or you can easily
configure dotnet build command(if dotnet is present in your build
servers).
Or you can refer the MusicStore build.cmd file for reference. This basically downloads and installs the dotnet and all the dependencies and then builds the project.
Hope it helps!
I found a workaround; in the project file, VS puts this:
<OutputTypeEx>library</OutputTypeEx>
I need to add one line:
<OutputType>Library</OutputType>
<OutputTypeEx>library</OutputTypeEx>
So it looks like the build with TeamCity is not handling the OutputTypeEx propery but it handles the OutputType one.
I still see this as a bug, but at least there is a workaround.
I've created an F# project using one of the Nancy templates in VS2013.
The code is basically just what the template created.
I can import the created .sln file into Xamarin studio and it all builds and runs without any errors or problems.
When I try to push the project up to Heroku though I get the error:
/tmp/build_b3e2706f-20c8-421e-a1ce-781831880466/NancyFirstProject/NancyFirstProject.fsproj: error : /tmp/build_b3e2706f-20c8-421e-a1ce-781831880466/NancyFirstProject/NancyFirstProject.fsproj: The required attribute "Project" in Import is empty
I've set the buildpack on Heroku as follows:
heroku config:set BUILDPACK_URL=https://github.com/aktowns/mono3-buildpack.git
I've read that a similar error can occur if you are upgrading a project via VS2013.
Is this the same error as I'm getting?
Is there another buildpack I can use that resolves this issue?
I guess I can create the solution in Xamarin but I'd like to stick to vs2013 if possible.
EDIT: **
Just noticed this in the .fsproj file:
<Choose>
<When Condition="'$(VisualStudioVersion)' == '11.0'">
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</When>
<Otherwise>
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
</Otherwise>
</Choose>
<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />
I'm not entirely sure why this does not work, but I had to get rid of the <Choose> tag in the F# project file in order to get F# Formatting project to work on Travis (building using Mono) and the change I had to do looks like this (GitHub diff). Sorry for the lack of clarity - I probably copied this from some other project.
The diff replaces the <Choose> tag with:
<PropertyGroup>
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
<PropertyGroup Condition="'$(VisualStudioVersion)' == '11.0' Or $(OS) != 'Windows_NT'">
<FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>
</PropertyGroup>
This issue can now be resolved by using the buildpack from here and specifying a later version of the .net framework.
I have .sln file which has around 352 projects.
I have created batch file below
"C:/Windows/Microsoft.NET/Framework/v4.0.30319/msbuild.exe myproj.sln /nologo /t:Build /p:Configuration="Debug" /property:Platform="Win32"
pause"
But this builds all the projects from solution. I have configured "Configuration Manager" to unselect unwanted projects or unload project and used above batch file to build but that did not serve the purpose.
I have searched MSBuild options but could not find exact answer.
Can anyone help me in this ?
MSbuild accepts project name as part of "target" (/t) specification:
MSBuild /nologo /t:ProjectName:Build SolutionFile.sln
Or, if your project does not depend on other projects in solution, directly use project file with MSBuild:
MSBuild /nologo /t:Build ProjectFile.vcxproj
This trick works with Visual Studio 2010, 2012, 2013, 2015, 2017, 2019 and with the latest MSVS 2022.
You could make a solution containing just the projects you want to build. Alternatively you could make an MSBuild .proj file that collects together the projects you want to build:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectsToBuild Include="X.csproj;Child\Y.csproj" />
</ItemGroup>
<PropertyGroup>
<Configuration>Release</Configuration>
</PropertyGroup>
<Target Name="Build">
<MSBuild Projects ="#(ProjectsToBuild)" ContinueOnError ="false" Properties="Configuration=$(Configuration)">
<Output ItemName="OutputFiles" TaskParameter="TargetOutputs"/>
</MSBuild>
</Target>
</Project>
Derived from http://sedodream.com/PermaLink,guid,ed3a0c98-fdac-4467-9116-5b3bf6755abc.aspx.