I'm updating some VS SharePoint projects so when they are built, both dll's and wsp's (packages) are created.
I found this page describing the process, but issue is that, while my project file looks like this:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets" />
<PropertyGroup>
<BuildDependsOn>$(BuildDependsOn);CreatePackage</BuildDependsOn>
</PropertyGroup>
<PropertyGroup>
<PostBuildEvent>"$(SolutionDir)PostBuild.cmd" "$(SolutionDir)" "$(TargetDir)"</PostBuildEvent>
</PropertyGroup>
PostBuild.cmd is run BEFORE packaging happens, so when starting clean, this is the output:
------ Rebuild All started: Project: Sample, Configuration: Debug Any CPU ------
SampleProject -> C:\Inter\bin\Debug\Sample.dll
C:\Inter\bin\Debug\Sample.dll
1 File(s) copied
File not found - *.wsp
0 File(s) copied
Successfully created package at: C:\Inter\Sample\bin\Debug\Sample.wsp
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Any ideas? Thanks!!!
Solution can be found here.
Visual Studio & SharePoint: how to create package as part of the build
process In order to build a project and have the package created, this
can be added to the project file (csproj, vbproj):
<PostBuildEventDependsOn>
$(PostBuildEventDependsOn);
CreatePackage;
</PostBuildEventDependsOn>
That's right. PostBuild event occurs after buiding assembly.
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've upgraded to a new windows 10 development machine.
Everything works great, except post-build events in msbuild/visual studio.
This is for any project, new or existing.
They all work fine on other people's windows 7 machines.
They work fine on the build server (jenkins).
They do not work for me at all, either in visual studio or with msbuild.
PRE-build events works fine.
It's like the postbuild event isn't even defined.
Unfortunately, our postbuild events are fundamental to the build process.
Starting with a basic console app and configuring the build events as:
<PropertyGroup>
<PreBuildEvent>echo before build</PreBuildEvent>
</PropertyGroup>
<PropertyGroup>
<PostBuildEvent>echo after build</PostBuildEvent>
</PropertyGroup>
The build output is literally:
1>------ Rebuild All started: Project: ConsoleApplication1, Configuration: Debug Any CPU ------
1> before build
1> ConsoleApplication1 -> C:\dev\postbuild\ConsoleApplication1\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Running msbuild with /v:diag I get this section:
PostBuildEvent = echo after build
PostBuildEventDependsOn =
PreBuildEvent = echo before build
PreBuildEventDependsOn =
When running prebuild:
Target "PreBuildEvent: (TargetId:22)" in file "C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets" from project "c:\dev\postbuild\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.csproj" (target "CoreBuild" depends on it):
Using "Exec" task from assembly "Microsoft.Build.Tasks.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "Exec" (TaskId:19)
Task Parameter:WorkingDirectory=bin\Debug\ (TaskId:19)
Task Parameter:Command=echo before build (TaskId:19)
echo before build (TaskId:19)
before build (TaskId:19)
Done executing task "Exec". (TaskId:19)
Done building target "PreBuildEvent" in project "ConsoleApplication1.csproj".: (TargetId:22)
When running PostBuild:
Target "PostBuildEvent: (TargetId:77)" in file "C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets" from project "c:\dev\postbuild\ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.csproj" (target "CoreBuild" depends on it):
Done building target "PostBuildEvent" in project "ConsoleApplication1.csproj".: (TargetId:77)
I have added the following AfterBuild task to a .vcxproj file:
<Target Name="AfterBuild">
<Message Text="Hi" Importance="high" />
</Target>
It seems to run only if the the C++ code is built (or if I do a rebuild):
1>------ Rebuild All started: Project: ConsoleApplication1, Configuration: Debug Win32 ------
1> stdafx.cpp
1> SomeClass.cpp
1> ConsoleApplication1.vcxproj ->
1> Hi
D:\Projects\CppTest\Debug\ConsoleApplication1.lib
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
It doesn't run when the the C++ code is up-to-date:
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
How can I make it always run? I'm using Visual Studio 2015.
The line
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
means that Visual Studio didn't run MSBuild at all.
For incremental builds VS uses File Tracker to intercept file operations being performed by compiler and linker. Results can be fould in ProjName.tlog folder. In subsequent builds VS checks dates of files listed in .read and .write files and decides whether to run MSBuild. This feature is described in Hashimi S., Bartholomew S. - Using MSBuild, 2nd Edition - 2013, "File Tracker" chapter.
Some of possible solutions:
Use FileTracker API in your custom build tool.
Manually write file name(s) produced by your tool in some .write file (this solution is simple but is not guaranteed to work in future VS versions).
Build your solution by MSBuild instead VS.
Build your solution from bat-file, which calls devenv first then your tool.
I got around this issue by adding the following lines to my .vcxproj file:
<PropertyGroup>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
It seems to force the IDE to actually run MSBuild.
I tested it in Visual Studio 2015. Adding the same lines to an imported .targets file did not help.
There is a setting "Run the post-build event:" in project properties in Visual Studio, and you need to set it to: "Always" for the post-build event to run always.
I guess it's now set to "On successful build".
Build your project with detailed logging (/v:detailed or /v:diag) and find the target which being run last but present in both cases (lets say it's a made up target "FinalCleanup"), then hook your post-build target like this rather than by the special name
<Target Name="RunMyLastTarget" AfterTargets="FinalCleanup">
<Message Text="Hi" Importance="high" />
</Target>
I finally went with Custom Build Step. To ensure that it always runs I set the Outputs field to some dummy file path. Since the dummy file path is never present, the Custom Build Step always runs. It is hacky, but it gets the job done.
I'm using Visual Studio 2010 and BizTalk 2010.
When I add a new Empty BizTalk Server Project and build it, I get the following output:
------ Build started: Project: ThrowAway1, Configuration: Debug Any CPU ------
ThrowAway1 -> c:\...\Projects\ThrowAway1\ThrowAway1\bin\Debug\ThrowAway1.dll
ThrowAway1 -> c:\...\Projects\ThrowAway1\ThrowAway1\bin\Debug\ThrowAway1.dll
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
I already tried deactivating the release build. But I still get two build events - which also affects the post build event.
With a default console application I get only one build event.
My goal is to run my own deployment PowerShell script in the post build event. The script is coming along nicely but it is called two times by this behavior.
This appears to be the expected behavior of a BizTalk Project.
I'm only speculating that it's because many BizTalk artifacts are compiled in a two step process. Orchestrations to C# then C# to the output Assembly for example.
The only thing I can recommend is to either make the script deterministic or maybe a side project that runs the post build for the entire Solution.
You can also investigate the BizTalk Deployment Framework: http://biztalkdeployment.codeplex.com/
As a pragmatic solution:
Checking the .btproj MSBuild file and its imports
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\BizTalk\BizTalkC.targets" />
where BizTalkC.targets imports
<Import Project="$(MSBuildExtensionsPath)\Microsoft\BizTalk\BizTalkCommon.targets" />
shows the usage of $(SecondBuild) in BizTalkCommon.targets.
This can be used in the post build event:
if "$(SecondBuild)"=="true" (
rem Run script.
)
For the first build $(SecondBuild) will be empty/undefined.
After some changes to my project, Visual Studio started to always re-compiles all sources, causing all dependent project to also re-compile, slowing down development considerably. Why is that?
Happens only when XML documentation file is checked and there's some file with Copy always. If you change either of these, the sources don't get re-compiled.
Happens only when compiling inside Visual Studio - when compiling using MSBuild from commandline, the sources don't get re-compiled.
Visual Studio 2012 Update 4.
This appears to be a bug in Visual Studio, when project has XML documentation file checked some files with Copy always.
Repro:
Create new project - C# class library.
Project Properties => Build => check XML documentation file
Project => Add => New Item => Text file TextFile1.txt
Change TextFile1.txt Copy to Output Directory to Copy always
Right-click project => build
project compiles
Right-click project => build
Expected: Project shouldn't be built, build output should say:
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
Actual: Project is build, output is:
------ Build started: Project: ClassLibrary1, Configuration: Debug Any CPU ------
ClassLibrary1 -> bin\Debug\ClassLibrary1.dll
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Intestigation: Turning on detailed log, you see:
Target "CoreCompile" in file "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.CSharp.targets" from project "ClassLibrary1.csproj" (target "Compile" depends on it):
Building target "CoreCompile" completely.
Output file "bin\Debug\ClassLibrary1.XML" does not exist.
Looking in procmon, you see that devenv.exe renames "ClassLibrary1.XML" into "vsA381.tmp" just before MSBuild.exe runs. Stack trace for the rename:
KERNEL32!MoveFileW+0x17
csproj!CMoveOutOfTheWayScope::EnterScope+0x85
csproj!CVsProjBuildableProjectCfg::StartBuildProcessWithTarget+0x50b
csproj!CVsProjBuildableProjectCfg::StartBuildProcess+0xc
csproj!CVsProjBuildableProjectCfg::StartBuildEx+0x15
msenv!CSUIBuilder::DoBuild+0x1a3
msenv!CSUIBuilder::Run+0x66