Since TeamCity supports many languages, this question might be very tight coupled with the way, projects work in Visual Studio. So here is my question:
For instance, I have a project A in Visual Studio, and I want to add it to TeamCity in order to support continues integration. Now there is another project B. This project depends on project A. Now, how do I reference project A in project B? And how do I update it properly? I know that I can generate artifacts in project A, but I think I'm supposed to download them manually?
You could use NuGet for that. Please take a look at this blog post for more details about TeamCity + NuGet integration.
Related
I know that I can define a specific build order using dependencies in Visual Studio, but my question is do those dependencies and build order stay the same whenever I check-in my work to TFS and run a build on the TFS server? I ask because I am having some issues when it comes to having multiple projects in the same solution where project B references project A, and project C references project B, etc.
The solution builds locally just fine because I have set the dependencies such that project B always builds first, but it doesn't seem like this configuration carries over to TFS.
Is this possible to do on the TFS build side?
TF Build will build your projects in the same order, dependency order, that they are built in Visual Studio.
If you reference a project (no reference a projects output but the project) then it will all cascade correctly. Direct Binary references do not cascade correctly as both VS and MSBuild assume it is already built.
Make sure your updated solution file, with the build order, Is committed to TFS.
Ensure that your build is targeting this solution file rather than a list of projects.
As others have said Project References are the key, check all references point to the project and not the binary output.
If the references are correct then the build order will be correct automatically and manual intervention is only really required for projects such as wix projects where the installer project should always be built last after all of the other outputs have been completed.
I have my own TFS (visual studio online) and work TFS. In my TFS located my own projects and, in particular, the project with useful utilities. I want to connect it to the work TFS solution, but keep getting an error, which essentially boils down to the fact that you can not connect a project in more than one TFS. Can I achieve the desired result?
No you cannot use multiple Team Foundation Server instances at one time. When you switch a project, you switch to the TFS server that it's stored in.
The recommended way to share utility code like you're talking about is by sharing only the binaries. This can be done using NuGet. You can setup your own NuGet repository and then let your utility project publish to your NuGet server. Other projects can include your NuGet packages just as you use external packages.
You can find a great overview of what NuGet can do here.
In every tutorial and HowTo site (like here) about WiX I read I should add reference to my other project, but when I select Add Reference I have nothing on Project list in Project tab. I try this on Visual Studio 2012, earlier with WiX 3.7 and now on 3.8.
If there is solution simply not using "Add Reference" function how can I build this other way? I'm a beginner so I don't really know how to use WiX without this feature, if I published my C# application in Publish Wizard I should add all produced files to Component Group with every file in <Component> tag?
It could be this simple...
In Visual Studio, Add Reference's Project tab only lists projects in the same solution. You just need to Add Project to the solution and go back to the Add Reference's dialog.
A solution is just a set of zero or more projects that can be built together. You can have a project in more than one solution. The only limitation is that if project B references project A (B is downstream of A), A should be in every solution that contains B. If the universe of projects is small, it is typical to have only one solution for them all. On the other hand, if one developer works only on upstream projects, that developer might find it easier to work with a solution that doesn't have downstream projects.
Setup projects tend to be downstream but note that they probably don't depend on library test projects.
[Stream is not the best technical term. The universe of connected projects is a directed acyclic graph.]
Normally "continuous package integration" involves source control, a build server, and participating teams fetching updated packages as often as they like. But I'm looking for a more extreme version of this story - without CM - that happens entirely on a developer's machine, all in one swoop. A more detailed description of what I want goes like this...
Using Visual Studio 2010 or 2012, assume a "foo.csproj" application that implements a plugin system. Each plugin represents a nuget package and has a corresponding Visual Studio project. Each of these projects is part of the same VS solution that contains the base application.
I want the following development story:
Change source code for a plugin.
Build solution, or perform a debug-launch, which causes msbuild to...
rebuild the changed plugin(s)
nuget then packages and uploads each plugin to a local repository (which can be just a subfolder of the VS solution)
rebuild the base application.
refresh the base application's nuget-plugin dependencies, which were just updated in prior steps. Notes:
This assumes MSBuild magically knows not to perform this last step until all plugins are built, packaged, and uploaded.
The "foo" application could itself use nuget.core to refresh the packages, but in this case I'm assuming that the VS build process did this step.
I would like to know if this story is common enough that there are "common" (msbuild?) scripts for this.
My own guess of how this should be handled is as follows:
All plugin projects are placed in a common "Plugins" folder somewhere in the VS solution folder structure.
The base application "project dependencies" are configured with references to all the plugin projects.
Note: I don't like the idea of managing these project dependencies manually.
The base application "foo.csproj" has a build step that scans the "foo.csproj" XML for dependencies it has in the "plugins" folder, and initiates the nuget packaging and deployment for each.
The base application then initiates the nuget "update all". Hopefully this is possible even though msbuild already mid-stride in execution.
In short, the base application is able to instantly consume plugins that have been altered. This is done without check-ins, a build-server, or manual and arbitrary requests to update plugin packages.
If pre-existing scripts do not already exist for this story, then I'll make my own. But I'd still like to know:
Can step 2, immediately above, be converted to something generic? That is, how can I convince msbuild not to build the "base application" until all projects in a particular folder have already been built? Remember, I'd like not to manage the project dependencies manually.
Is there anything flawed with this overall approach?
I would be particularly interested to know if there is an already existing nuget-visual-studio integration that assists with this story that I may have overlooked.
That's quite a long question to answer, so not sure I'm covering everything in this one; I'll do my best. First, your scenario is not uncommon. The first 2 steps of your planned approach seem OK to me (you're free to choose the location of the plug-in projects).
One thing's for sure: you'll have to manually define the build order, because your solution has no idea of knowing whether the projects consuming (NuGet) plug-ins have a dependency to the projects containing the source code for those plug-ins. Instead of using the built-in Build Order dialog in Visual Studio, take a look at this post on the MSDN blog for a correct way of doing this (or you might end up with something that works locally but not on the build server).
The key MSBuild elements in the referred post are the following:
<ProjectReference Include="... foo.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Now, as for the packaging, deployment and consumption of those plug-ins:
Each plug-in project should trigger package creation and publication in a post-build step. This post on my blog contains ZIP-download with quite lot of MSBuild stuff you can use to get started. E.g. I version, package and publish the NuGet package for a class library in Release builds. I'm using the NuGet command line tool to pack (command reference) and push (command reference) the package.
The consuming application project(s) should run NuGet.exe update <packages.config> (command reference) in a pre-build step.
Also pay attention you're NOT running builds in parallel.
I'm making a build using FinalBuilder Pro 7.
I've an ASP.NET web site and I'm trying to use FinalBuilder's "Precompile Asp.net 2.0 Application" action. Well, It fails.
To build it successfully I need to run Visual Studio, open the web site and either build it manually from within VS or manually update all references. After that it works.
Now the question: How to force FinalBuilder to update those references? Even if I create web deployment project associated with the web site and try to build it with msbuild action it would fail for the same reason. Somehow neither action updates references automatically.
Update: OK. Maybe I need to force msbuild to update references. How to do that?
I found some properties that I can change at msbuild action.
On called ResolveAssemblyReferencesDependsOn I tried to put the value = true. Didn't help.
Any ideas?
There are different types of projects in .NET like library project, website project, web API project etc. As you mentioned in your question it is a website project, so I am going to give you a solution for website project.
You can build a project by two ways. Either you can build by visual studio or you can build by using MS Build. If you build your project by using VS, you can update references of your dependencies by executing the command "Update-Package -reinstall" in package manager console. It will reinstall all the packages automatically.
Please note that, all your dependencies are listed in packages.config file.
Secondly if you have to build your project by MS Build using cmd prompt, to load all the dependencies from nuget, you have to execute nuget.exe. By which all your dependencies will be loaded, but their references may not be updated. So in website project you do not have .proj file. So you can't have access to the references of your dependencies. Now problem is that how you can modify your dependencies references?
In website project reference of an assembly exists in its .refresh file. So you have to modify that .refresh file to update the reference of an assembly in website project.
Have you tried using the 'Build VS.NET Solution' or 'MSBuild Project' actions? Both should resolve your assembly references, provided the reference is set to the right location. This requires that you at least have a project file.
As I understand it, the Precompile action (which uses the MS aspnet_compile.exe - see http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx) is designed to re-compile an asp.net application which has previously been built via VS or MSBuild. It does either an in-place compile to improve performance for the first user that hits the site, or creates a deployable application (removing source code etc). It's not meant as an alternative to VS/MSBuild.
I'm not 100% sure I understand the problem, but I believe you need to be able to correct some pathing on an assembly reference automatically.
I created a project to handle this (along with some other things): refswap.codeplex.com