I added into Solution(contains 30projects) Wix Installer, which is supposed to pack web service folder. Among files i want to pack is BIN file with plenty of dlls. On local with Release mode it works fine, however if i run TFS 2013 build definition over solution i get these:
C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\filesToBeInstalled.wxs (97):
The system cannot find the file 'C:\Builds\1\ABCD_02\WixInstaller\WSwixInstaller\..\..\..\ABC WS\bin\ABC.Components.DataAccess.Lib.Utils.dll'.
I asked my colleage who administrate server and he told me that BIN folder isn't created in 'expected' location.
Now i don't have access to server and colleage is unreacheable, is here rule where binaries for all project/within solution are stored?
Update:
Somehow we overlook BIN folder - 'as configured' is and was set in definition however files still couldn't be found - problem was in build order(weirdly in VS2010 was correct) setting dependency wix project on target project helped - problem was that wix project was builded before target one.
Team Build creates uses a MsBuild parameter to redirect the build output of projects. If you need your Wix Installer to package up content that has been redirected, your installer script must be aware of this redirection happening.
The output structure of team build looks like
Build Agent Root
+- Unique build folder
+- src <- This is where your Wix project is placed
+- bin <- This is where Team Build redirects the project outputs to.
+- Test <- This is where Test Results are stored
This allows Team Build to figure out which outputs to copy to the drop location with a lot more accuracy, but it breaks any scripts that have hardcoded (or relative) paths to build outputs.
There is hope though, you can use the $(OutDir) or $(OutputPath) parameter to find the location Team Build has been configured to drop your binaries. You can use the '$(BuildingInsideVisualStudio)'=='' and/or '$(TeamBuildConstants)'=='' to detect whether your Wix Script runs in Visual Studio or in Team Build.
That way you can define multiple source locations for your Wix packages or to set the base directory to a certain value and use that variable in your wix scripts.
Or if you simply want your team build to match your bin structure when running in visual studio, set the 'output location' parameter in your build definition to 'as configured' - see this link for details:
http://blog.stangroome.com/2014/02/10/override-the-tfs-team-build-outdir-property-in-tfs-2013/
Related
We just upgraded to TFS2015 (onsite) and I'm trying to set up a build that will do the same thing as my xaml builds but I can't seem to get the same files built. Here's a picture of the xaml output directory that I use to publish the site. To get this I navigate to the build folder then drill down to the _PublishedWebsites\BOTWSitecoreWeb folder:
Here's a picture of the solution explorer:
So as you can see BOTWSitecoreWeb is my startup project and it forms the basis for the website. So to publish this website I simply copy the folder: _PublishedWebsites\BOTWSitecoreWeb to my IIS directory. Here's what it looks like using the xaml build:
And if I drill down into the TFS2015 build output folder into the Drops/Source/sc/Website folder I get this, which has many more files and folders than what I'm expecting:
So my question is how can I get the same output that I currently get from my xaml builds from a TFS2015 build?
The bin folder has the same number of files, so that's a good start. Here's the bin folder from the xaml build:
And here's the bin folder from the TFS 2015 build. Notice that they both have 57 files, which I assume is a good thing!
Thanks in advance for any insight you can provide!
Ben
Update your build definition to below:
Add /p:DeployOnBuild=true /p:OutDir="$(build.artifactstagingdirectory)\\" arguments in Visual Studio Build step:
Change "Path to Publish" of "Publish Build Artifacts" task to "$(build.artifactstagingdirectory)_PublishedWebsites\ProjectName":
Save the build definition and queue a build, now you should get the same files published in drop folder like XAML build.
vNext build and XAML build, it's totally different technology. There won't be any automated ways of converting.
The new builds are based on a different architecture and run on a
completely different system.
So your situation is predictable, it's very hard to achieve a 100% conversion. Copy the folder in vNext will copy everything under the folder by default. Seems there are some customization during the copy or published in your XAML build which will return the result as above picture.
If you have heavily customized XAML builds and custom activities, you
can continue using those builds until you are ready to port your
business logic into scripts that can run in the new builds.
And you could also take a look at these series of articles how to upgrade from XAML to Build 2015 with minimal changes.
I am trying to make changes to the WixStandardBootstrapperApplication.cpp and generate a dll as per the suggestion from this link. I have downloaded the wix310-debug source and am modifying the file present under wix310-debug\src\ext\BalExtension\wixstdba\ location. There is a wixstdba.vcxproj file under this location which I am trying to open using Visual Studio 2012. Whenever I try to do that I get the error:
Unable to read the project file "wixstdba.vcxproj". The imported project "C:\tools\WixBuild.props" was not found.
I am not sure what should I do to correct this. Also, based on the referenced link, I think I am updating the correct file but let me know if that is not the case. Any help in this would be great. Thanks in advance.
In your vcxproj there's a line like this:
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildProjectDirectory), wix.proj))\tools\WixBuild.targets" />
The debug source isn't really the source of wix. It includes all the wix source files but it is not really buildable. This zip has all the built pdbs and is used to debug only.
You want to download the wix source from wixtoolset's github so that you can build wixstdba. But, this is for version 3.10.3 currently and may have some version specific changes but I don't see anything that would be an issue using the dll built here against wix 3.10.2 since the engine and bootstrapper application interfaces should have remained the same.
But, you should be able to build all this with only the WixStdBA project. You will have to copy over the wixstdba folder. Edit the vcxproj and remove the import line mentioned above (it should be near the bottom).
Now, add this project to your a new solution or your installer solution in visual studio. We need to add addition include and library directories. All these include directories will be in your wix install location (default C:\Program Files (x86)\WiX Toolset v3.10) In Properties -> C/C++ -> General -> additional include directories add your wix SDK include path. If you are using visual studio 2013 you can use the full path or you can use "$(WIX)\SDK\vs2013\inc". $(WIX) should reference the WIX environment variable which points to the install directory which is added when installing wix. This should be the better option if you will be building on a build system with wix installed since the location may be different across machines.
Now for addition library directories, we go to the Properties -> Linker -> General -> Additional Library Directoryes and add in the correct lib path. If you are using visual studio 2013 you want to put in $(WIX)\SDK\vs2013\lib\x86. Finally we need to reference the libs that are needed to build the bootstrapper dll. Under Linker -> Input -> Additional Dependencies, add in "dutil.lib;balutil.lib". My additional dependencies has a lot more stuff and I don't remember if it was by default there. Here's my Additional Dependencies in full anyways
dutil.lib;balutil.lib;advapi32.lib;comctl32.lib;comdlg32.lib;gdi32.lib;gdiplus.lib;kernel32.lib;msimg32.lib;odbc32.lib;odbccp32.lib;ole32.lib;oleaut32.lib;shell32.lib;shlwapi.lib;user32.lib;uuid.lib;wininet.lib;winspool.lib;version.lib;%(AdditionalDependencies)
With this you should be able to build the wixstdba project and get a dll built. Without editing any code this should be the exact same as the wix included wixstdba.dll.
You could try referencing this dll instead of the wix included one (have to define your own BootstrapperApplication instead of using the BootstrapperApplicationRef to one of the wix ones) or just drop in this dll into your wix location's bin.
I am using Windows installer xml and now my project moves to Team Services.
However, my Paths wont work anymore and I need to update my setup.
On the local build machine I used this hardlink: C:\Projects\Solution\Project\bin\Release\Assembly.dll
My Question: What is the best way to build 4 projects and then run a 5th project, which uses the assemblies in the bin/release directory?
Add a reference to the project and then use $(var.Project.TargetPath) instead of the hardlink (or $(var.Project.TargetDir)Assembly.dll). The references will add dependencies on those projects to the wixproj which means they all must be build before the wixproj so all the binaries will exist. All the projects should be included in the same solution as the wixproj.
Here's a resource for all the automatically defined compile time variables you can use http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html
Alternatively if you can't do it this way you can define the variables in the <DefineConstants> of the wixproj. It would be something like "ProjectDir=$(MSBuildThisFileDirectory)..\Project\bin\Release\" and then in your wix component where you are using the SourceDir hardlink you would use SourceDir=$(var.ProjectDir)Assembly.dll
All of this stuff is taking advantage of MSBuild. It takes a long time to wrap your head around how MSBuild works but it is definitely worth it if you will be using Visual Studio to build all your projects.
I am using Wix 3.9 and when I run a continuous integration build in TFS I get an error
heat.exe: The directory could not be found because TFS is putting binaries in a different location to my local machine, so the project will build locally but not on TFS.
In my wixproj file I have a location set for the binaries which works locally
Dir=$(SolutionDir)\ProjectName\bin\$(Configuration).
Is there anything I can set this to which will find the binaries both on my local machine and TFS?
I am looking for something like the project reference variable $(var.MyProject.TargetDir), but this doesn't seem to work in wixproj files.
I worked around this issue by changing my project files to output the binaries to the same location as Team Foundation Build. That way both desktop and continuous integration builds can use the same reference to the common binaries directory.
If you are using Team Foundation Build 2012 or earlier your directory reference would be: Dir=$(SolutionDir)..\Binaries\$Configuration. The corresponding output path in a C# project would be ..\..\Binaries\Release or ..\..\Binaries\Debug (assuming the project folder is located in the root of the sources directory).
If you are using Team Foundation Build 2013, the same technique can be used, but the Binaries folder becomes bin. Your directory reference becomes: Dir=$(SolutionDir)..\bin\$Configuration. A similar change is required to the project output folders.
Team Foundation Build 2013 has additional options to control the output location, where you can put the output binaries in the same layout as your project structure. I've not used that personally but that might provide a solution.
I am newbie to TFS.
I am trying to automate process of build upon checking in the code in TFS.
I setup a Controller and an Agent. I created a new build definition and set a "build" and "drop" folder on c:.
I check in the code, expecting to see the generated dll files in "drop" folders. There's none, just "logs" folder. The "binaries" folder in "build" folder is also empty. Apparently the binaries are not being generated at all. How can I have MSBuild to generate the dll files?
They are generated when I compile the website locally on my development machine under "bin\" folder. The solution is comprised of two separate projects: "core" and "web" where "core" is referenced within "web".
Any thoughts?
What is the Summary showing of your build that ran? Or are there errors in your build? You can check the log of the build by opening the build in Visual Studio and then click View Log.