I have got the following structure:
$
--TeamProject1
---Solution1.sln
----TestProject1
--TeamProject2
---Solution2.sln
----TestProject2
In TestProject1, I add TestProject2.dll as reference (Not a project reference, but a file reference). My question is: how to build a solution that reference to assemblies belonging to different team project?
I have got TFSBuild.proj file containing the following info:
<TfCommand>$(TeamBuildRefPath)\..\tf.exe</TfCommand>
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../DEV/TeamProject1.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
<Map Include="$/TeamProject1">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Map Include="$/TeamProject2">
<LocalPath>$(SolutionRoot)</LocalPath>
</Map>
<Target Name="BeforeGet">
<DeleteWorkspaceTask TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Name="$(WorkspaceName)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workspace /new $(WorkspaceName) /server:$(TeamFoundationServerUrl)" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /unmap /workspace:$(WorkSpaceName) "$(SolutionRoot)"" />
<Exec WorkingDirectory="$(SolutionRoot)" Command=""$(TfCommand)" workfold /map /workspace:$(WorkSpaceName) /server:$(TeamFoundationServerUrl) "%(Map.Identity)" "%(Map.LocalPath)"" />
</Target>
Thanks in advance.
Xiaosu
To quote the official TFS guide on CodePlex:
If you share source or binaries across team projects, you have two options:
Branching. With this approach, you branch the source from the other team project into your current solution. This creates a configuration that unifies the source from the shared location and your project on the server-side.
Workspace Mapping. With this approach, you map the source from the other team project into a workspace on your development computer. This creates a configuration that unifies the source from the other team project and your project on the client-side.
Branching is the preferred approach because it stores the dependency relationship on the source control server. Workspace mapping is a client-side-only approach, which means that you and every developer must create the mapping on your own computers and also on the build server in order to successfully build the application.
Branching adds additional merge overhead but it enables you to make the decision to pick up updated binaries or source more explicitly.
AFAIK this is not possible and it will be problematic on developer's machines. File references is the way to go. I usually organize projects like this:
$
-- TeamProject1
-- branches
-- trunk
Solution1.sln
-- lib
TestProject2.dll
-- src
-- test
TestProject1.csproj references TestProject2.dll from lib
-- TeamProject2
-- branches
-- trunk
Solution2.sln
-- lib
-- src
-- test
TestProject2.csproj
This way TeamProject1 is independent from the source code of TeamProject2 and it contains all the necessary dependencies. If TeamProject2 changes it won't necessary break TeamProject1.
It was very difficult to find the actual answer for this and it wasted a lot of my time. So if you ever get this problem, here is a link to the correct solution
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/9918911f-5951-43be-9ee9-00214cf17400/buildvnext-and-multiple-team-projects?forum=tfsbuild
Basically the UI does not allow you to select more than one team project on your collection. But you can always type the actual path to your other team projects and it will work
Related
I'm working on a TFS project where the previous developers have included everything in source control - including the bin and obj folders.
When I try to build the solution, I get a few errors because all of the files in the bin and obj folder are locked as read only.
For reasons I can't control, these folders have to be tracked in TFS. How else can I fix the problems caused when I try to build the project and get errors because these folders are locked?
How can I build the solution without checking out these folders every single time?
Don't add the obj and bin folders to source control. To remove them from TFS, open Source Control Explorer in Visual Studio, simply right-click on the folders and choose "Delete".
If you can't remove them then you should ask the person who has control over TFS. I don't see any reason to add these folders to TFS so it shouldn't be a "constraint".
As previously mentioned, there is no reason to have have bin and obj folders included in source control, their contents are volatile.
But if you really have no control over that, you simply need to make the appropriate folders and files writeable so they can be overwritten, or delete the bin and obj folders after making them writeable. This is relatively straightfoward, there are a couple of ways to achieve it, and it requires changing the TFSBuild.proj file for the appropriate build.
To make a specific file writable, use this:
<Attrib Files="[path to your file]" ReadOnly="False"></Attrib>
For making the contents of a whole folder writable, use batching to get a list of the files, then iterate over them using the attrib task:
<Target Name="MakeFilesWriteable">
<Attrib Files="#(TargetFiles)" ReadOnly="false" />
</Target>
<ItemGroup>
<TargetFiles Include="[path to bin folder]\**\*.*" />
</ItemGroup>
Alternatively you can execute a Delete on the bin folder:
<RemoveDir Condition="Exists('[path to bin folder]')" Directories="[path to bin folder]" />
With the exception of the batching example, these tasks can be placed directly within the BeforeCompileSolution override target of the build proj file; for the batching example you simply do a call target. Pick and choose which method you want to use, then your BeforeCompileSolution will look something like this:
<Target Name="BeforeCompileSolution" >
<CallTarget Targets="MakeFilesWriteable" />
<Attrib Files="[path to your file]" ReadOnly="False"></Attrib>
<RemoveDir Condition="Exists('[path to bin folder]')" Directories="[path to bin folder]" />
</Target>
Yon can use the powershell to delete the bin & obj folders recursively.
Get-ChildItem .\ -include bin,obj -Recurse | foreach ($_) { remove-item $_.fullname -Force -Recurse }
Here's a suggestion that is not technical. Since someone else created this problem for you, make it their problem. Tell them, and anyone else who matters, that you can't build and it's because of what they did. They broke the build; they should fix it. All the technical workarounds suggested here are nice, but they really just skirt the true problem.
Ideally I'd be grabbing the outputs from the project spec itself, but heat.exe doesn't seem to support contentproj files as a project type, nor does it pick up the content if I pass in the game's main csproj.
Currently I have a pre-build step calling heat on the output folder, but that (a) feels dirty, and (b) produces a bunch of File tags referencing the source paths relative to the output folder, such that the build fails when it can't find them relative to the WiX project's folder.
I should note that I'm using Votive and my project layout looks like this:
- Main solution
- XNA "Metaproject" Folder
- Game
- bin/x86/Release (GameContent output appears here)
- GameContent
- WiX Project
I would very much like to minimize the number of times I have to specify a path like "../../Game/Game/bin/x86/Release/Content", because that's error-prone and depressing to type out. Prods in the right direction appreciated!
Assuming a contentproj is just a collection of files, what you can do is add the harvesting directly within the wixproj that is creating the installer:
<PropertyGroup>
<HarvestDirectoryNoLogo>true</HarvestDirectoryNoLogo>
<HarvestDirectorySuppressFragments>true</HarvestDirectorySuppressFragments>
<HarvestDirectorySuppressUniqueIds>true</HarvestDirectorySuppressUniqueIds>
<HarvestDirectoryAutogenerateGuids>true</HarvestDirectoryAutogenerateGuids>
</PropertyGroup>
<ItemGroup>
<HarvestDirectory Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "
Include="$(SolutionDir)\GameContent">
<DirectoryRefId>INSTALLDIR</DirectoryRefId>
<SuppressRootDirectory>true</SuppressRootDirectory>
<PreprocessorVariable>var.GameContentDir</PreprocessorVariable>
<ComponentGroupName>GameContent</ComponentGroupName>
</HarvestDirectory>
</ItemGroup>
You will need to add this manually to the wixproj file and you can repeat the HarvestDirectory for each directory if you require more than one.
To set the var.GameContentDir pre-processor variable edit the DefineConstants property:
<DefineConstants>GameContentDir=$(GameContentDir);</DefineConstants>
which will set the pre-processor var to the msbuild property:
<GameContentDir>$(SolutionDir)\GameContent</GameContentDir>
which means you can then modify this dependant on the build configuration. If you don't need to modify the path, just set a static value in the <DefineConstants> property.
This will then generate a wxs file in the obj directory each build which is then included assuming you have included the ComponentGroupName. If you have included the one you previously generated in your wixproj remove it as you will get conflicts if the ComponentGroupName is the same.
I have a projects in JAVA that I analyze using sonar. Some of the java packages that I have are all under source folder. I also have some test file that I have under a different folders. Now, in Sonar, I organize my projects under a different structure, i.e. for a project "search", I only wants to include "search" package. These exclusion is quite easy to accomplished using sonar.exclusion properties. My question, though, is how about the test? how can I exclude some of the packages? Because from my testing, even though my source and test folder are using the same structure, the test packages are not automatically excluded when I specified "sonar.exclusions".
my folder structure:
/src/com/domain/
-- search/
-- utils/
-- pooling/
-- category/
/test/src/com/domain/
-- utils/
-- pooling/
Sonar properties:
<property name="sonar.sources" value="${path}/src" />
<property name="sonar.tests" value="${path}/test/src" />
<property name="sonar.exclusions" value="com/domain/utils/**/*,com/domain/pooling/**/*,com/domain/category/**/*" />
So, I am trying to only include the "search" package. The code above works in a way that it causes SONAR to only analyze my "search" package. This package can be seen in the SONAR "Components" tab. Unfortunately, in addition to the "search" component, I can also see the "util" and "pooling" components. I have done some testing and certain that these two components (utils and pooling) are the result of "sonar.tests" properties. Just a note though, even though "util" and "pooling" shows up in components, SONAR shows zero files under both of them. So going back to my question, is there anyway that I can do to exclude "util" and "pooling" from showing up under "Components"? Maybe using properties (i.e. sonar test exclusions)?
Btw, I am using SONAR 2.11 and is running under Red Hat linux. I'm using SONAR-TASK 1.2.
Any help is welcomed and appreciated! Thanks!
You can define exclusions in the Configurations for the project directly in sonar.
From the documentation:
Since version 3.3, it is also possible to:
Exclude tests file from being analyzed:
go to Configuration > Settings > Exclusions and set > the sonar.test.exclusions property
The trick is:
sonar.exclusions: excludes files from sources directory (i.e.sonar.sources), it has no effect on tests directory.
sonar.test.exclusions: excludes files from tests directory (i.e.sonar.tests), it has no effect on sources directory.
See https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus
And, Using sonar.test.exclusions with Sonarqube 6.3
I am coming up on the end stages of an Asp.Net MVC 1.0 project in VS2008 / Framework 3.5, and trying to do some performance optimizations. In my project, I have a few different "themes" that are used, depending on the role of the logged in user. My themes folder structure is like so...
\Themes
\Theme1
\Css
\Folder1
\CssFile1.css
\CssFile2.css
\Folder2
\CssFile1.css
\CssFile2.css
\Images
<Images go here>
\Theme2
\Css
\Folder1
\CssFile1.css
\CssFile2.css
\Folder2
\CssFile1.css
\CssFile2.css
\Images
<Images go here>
As new customers come on board, new themes will be added to this folder structure.
I am using the Yahoo! UI Library: YUI Compressor for .Net
(which is really cool) to minify and merge my css (and js) files.
I followed the example at http://yuicompressor.codeplex.com/wikipage?title=Sample%20MSBuild.xml%20File&ProjectName=yuicompressor to run an MSBuild script via a post-build event to do the minify/merge tasks.
Everything works great, except that when I use something like <CssFiles Include="..\Themes\**\*.css" /> in my ItemGroup to specify where to get the css files, all css files from every theme are merged into one file, like this...
\Themes
\SylesSheetFinal.css
What I want instead is to merge only the css under the themes, creating one css file for each...
\Themes
\Theme1
\StyleSheetFinal1.css
\Theme2
\StyleSheetFinal2.css
I am really new to MSBuild. Does anyone know how I can modify the sample to automatically walk over each of the theme folders and create a minified/merged stylesheet for each? The themes can be added or removed quite often, so I don't want to have to manually include each theme path to my ItemGroup. Instead, I want the MSBuild script to walk the subfolders underneath the Themes root automatically, regardless of the number of folders.
Thanks!
What you are trying to do can be accomplished with batching. Batching is the process of executing a specific task (or target) once for each unique batch. There are two types of batching; Task Batching and Target Batching. Task batching is the most common and what I think you need, based on the info provided here. Batching can be kind of confusing, but it is not too bad once you get a grasp on it.
Batching always involves the %() operator. Here is an example of Task Batching.
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Batching01.proj -->
<ItemGroup>
<Files Include="src\Src01.cs"/>
<Files Include="src\Src02.cs"/>
<Files Include="src\Src03.cs"/>
<Files Include="src\Src04.cs"/>
</ItemGroup>
<Target Name="Demo">
<!-- Not batched, i.e. Files is flattened and sent to the Message task -->
<Message Text="Files: #(Files)"/>
<Message Text="================" Importance="high" />
<Message Text="Filename: %(Files.Filename)" Importance="high" />
</Target>
</Project>
The output would be:
Files: src\Src01.cs;src\Src02.cs;src\Src03.cs;src\Src04.cs
================
Filename: Src01
Filename: Src02
Filename: Src03
Filename: Src04
It is too tough to fully describe batching in this post, but I've put together some really great resources available online at http://sedotech.com/Resources#Batching.
This will hopefully be an easy one. I have an F# project (latest F# CTP) with two files (Program.fs, Stack.fs). In Stack.fs I have a simple namespace and type definition
Stack.fs
namespace Col
type Stack=
...
Now I try to include the namespace in Program.fs by declaring
open Col
This doesn't work and gives me the error "The namespace or module Col is not defined." Yet it's defined within the same project. I've got to be missing something obvious
What order are the files in the .fsproj file? Stack.fs needs to come before Program.fs for Program.fs to be able to 'see' it.
See also the start of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!444.entry
and the end of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!347.entry
I had the same problems, and you are right, the order of the files is taken in account by the compiler. Instead of the Remove and Add pattern, you can use the Move Up / Move Down items in the context menu associated to the .fs files. (Alt-Up and Alt-Down are the shortcut keys in most of the standard key-bindings)
All of the above are correct, but how to do this in VS2013 is another question. I had to edit my .fsproj file manually, and set the files in exact order within an ItemGroup node. In this case it would look like this:
<ItemGroup>
<Compile Include="Stack.fs" />
<Compile Include="Program.fs" />
<None Include="App.config" />
</ItemGroup>
I had the same issue and it was indeed the ordering of the files. However, the links above didn't describe how to fix it in Visual Studio 2008 F# 1.9.4.19.
If you open a module, make sure your source file comes after the dependency in the solution explorer. Just right click your source and select Remove. Then re-add it. This will make it appear at the bottom of the list. Hopefully you don't have circular dependencies.
I'm using Visual Studio for Mac - 8.1.4 and i've noticed that some .fs files are not marked as "Compile". You can see this by Viewing Build Output and see if all your files are there and in the correct order.
I've had to manually make sure certain files are marked with "Compile", and have had to move them up and down manually until it "takes".