Share database Projects between Team Project Collections in TFS 2010 - tfs

I have a database project which uses link servers in several of the views and stored procedures.
According to Microsoft, Visual Studio 2010 database projects do not explicitly support link servers, but you can kind of hack it using References and SQLCMD variables:
http://msdn.microsoft.com/en-us/library/bb386242.aspx
My database (the database itself) has a link server conenction to a Warehouse database. The Warehouse database project is stored in a separate Team Project Collection.
Is there any way to add the Warehouse project as a reference in my project?

The following article explains how to use reference variables in a database project.
http://msdn.microsoft.com/en-us/library/bb386242.aspx
This is necessary when you are referring to a database that is not in the same solution (see the first chart, second row).
In my case, I will probably have separate solutions for each different business environment (internal apps, external apps, warehouse, etc.). Each of these solutions will have several databases. But the databases will need to refer to databases that are not in the same solution (ex., an internal DB might have stored procedures that pull data from an external DB).
In this case, I think the best solution is to refer to the .dbschema file that is generated when the project is built. You can configure a nightly build for each project, and have the build output be copied to a specific shared drive location. You could then point any database project to any other database’s schema by adding a database reference (described in the above article) to the .dbschema ( on the shared drive) for the database.
If you wanted to make it more sophisticated, you could modify the build template to copy the necessary .dbschema files from the build output into each project and check them in.
In the case where the database does not have a project and is not being actively changed, it will be necessary to create a temporary database project for the database so you can build a .dbschema file. The built .dbschema file can then be checked in to the dependent project, and you won’t have to generate it ever again unless it changes.
I’ll do my best at an example…
Problem:
Project ABC depends on the data warehouse, and on project XYZ. Project XYZ is in source control under a different solution, but the Warehouse is not in source control.
Solution:
Create a nightly build for project XYZ
Configure the build output directory to go to a shared drive
Create a custom build template for project ABC that will copy the XYZ.dbschema file in to the ABC project and check it in
In project ABC, right-click on “Database References” and add a reference to XYZ, specifying the XYZ.dbschema file (instead of the XYZ database project, which is outside the solution)
Create the reference variables to the XYZ project (not sure this is necessary…)
Replace references to XYZ in stored procs & views with the reference variables you created in the previous step (not sure this is necessary…)
Now the references in ABC to XYZ should resolve.
Create a new database project (this can be a temporary, throw-away project)
Have it pull the definition from the Warehouse (right click the project and select “Import from database”)
Build the project
Copy the Warehouse.dbschema file from the build output into the ABC project
In project ABC, right-click on “Database References” and add a reference to the Warehouse.dbschema file
Create reference variables for the Warehouse
Replace references to the Warehouse with the reference variables
Now the references in ABC to the Warehouse should resolve.
I don’t know if it will work just like that, but that is the theory. Hope it helps…

Related

Sync references with TFs in VS database projects

In db projects, when you add a database dac-pac for example as a reference use in a view to reference a third party database, that seems to be valid only for your local copy.
In VS 2015 I can;t seem to find how you add that as a build so that it syncs and compares with the version you store in source control.
If I check out a team project, create a view referencing a third party DB, create a dac-pac for that DB, add it as a database reference, save, build, check in, by default that reference isn't checked in to the server for another developer to check out in the latest version and therefor they will get reference errors.
Does anyone know how to sync these? I can't find an option to do so!
Also, it would be nice to be able to edit the dam things, For example if they are on a different server you must define that. But say the server changes, you can only edit it in your publish profile, however if you do that but someone else doesn't it will flag as a change for them.
You'd better add the .dacpac file to TFS version control. When others check out from other machines, get down the .dacpac file together with that db project.
Make sure that when other check out that file and the db project to their local machine, the relative path between them are same with that in your environment. Actually, in the .sqlproj file of your db project, it has defined the relationship.
For example, I put the .dacpac file under a folder named "DACPAC" and this folder is at the same level of my solution folder.
In the .sqlproj file:
<ArtifactReference Include="..\..\DACPAC\TestDB.dacpac">
<HintPath>..\..\DACPAC\TestDB.dacpac</HintPath>
......
</ArtifactReference>
Note: The "..\" mean go to the uplevel path from where the .sqlproj at. It has 2 "..\", so go 2 uplevels.

App_Data folder is not checked in with Team Foundation Server [duplicate]

I am working with ASP.NET C# MVC 5.
.mdf/.ldf files in App_Data do not appear on Pending Changes in team explorer. Therefore I can't check them into TFS(visual studio online). I've tried recreating the project a few times and none worked. What might be the cause for this?
Go to Team Explorer and locate Excluded Changes and you should find it excluded. Right click the App_Data folder and include it.
But you might want to reconsider including the database files. As you're developing and testing, every little database interaction will trigger a change and most of those are trivial. Also, if someone else is working on this project, they may not want your database file to overwrite theirs when they Get Latest Version.
If you're using Entity Framework Code-First, the database is automatically generated when you build the project I believe, otherwise you just run the Update-Database command to do it. This lets everyone collaborating have their own local database file to work with. You can also utilize migrations to make updates to the database structure. If you want the database to be generated with pre-populated data, you should utilize the Seed method.
This is a general question. As already answered by 'Ty Morrow' in above comment there is an initial Seed Method in Entity Framework which ensures that all values are inserted. However there are many scenarios that you also need to work with the latest added / removed DB entries not present in the seed method.
Please perform the following steps to ensure that your data directory file is included in the source control.
Click App_Data folder and on encircled toolbar click on Show All Files as shown below in the snapshot
Right Click on your MDF (Data Source) File and click on Include in Project
Right Click again on your MDF File and click on Include in Source Control
Simply Check in the file by Right Clicking on root project folder link and file show be now part of Source Control

Using wixlibs from another solution with TFS builds

We have installers referencing a wixlib file to get some common functionality. The wixlib is built in another solution then moved to a folder within that solution. When we try to build the installers with a TFS build, we get an error from light.exe:
light.exe: The system cannot find the file '..\..\..\Core\Common\assemblies\v1.0\Common.Wix.wixlib' with type 'Source'.
Our regular projects can reference \assembiles\v1.0, since we have some other common assemblies stored there. How do we get WiX to recognize this location during build?
You are referencing wixlib directly. So as far as I understand the TFS build process, it should be added to TFS project of your solution. TFS project shouldn't be dependent on the output of another non-dependent solution. It is at least bad practice. And in any case you can't guarantee this output would be generated before your project build on server.
As far as I remember, TFS build creates separate folder for each build and gets sources there. So your solutions are no longer on the same folder hierarchy level.
One more point in favor of explicitly copying wixlibs into your installer project: versioning - in this case any bugs made in the common library will not immediately break all projects that reference it. And you can gradually upgrade and test every project. Can you imagine auomatically downloading new version of any 3rd party dll on every build? Any change in that dll will immediately break your application even if changes are not critical to you.
Since the shared component and the active solution are in two separate projects in TFS, the workspace must be setup so that the relative paths for references remain intact. The easiest way to do this is to set your Build Agent Folder structure in Workspace in your TFS Build to have $(SourceDir) represent your root. However, don't change your Source Control Folder - that stays the same.
For example, say you have the following structure:
-TFS
|-SharedComponents
||-MyComponents
|-ProjectArea
||-MyProject
You would want to have the following two items in the build Workspace:
Source Control Folder Build Agent Folder
---------------------------------------------------------------------------------
$/ProjectArea/MyProject $(SourceDir)\ProjectArea\MyProject
$/SharedComponents/MyComponents $(SourceDir)\SharedComponents\MyComponents
This mimics the structure in TFS in your build folder, thus allowing all relative paths to remain intact.
One more note about this configuration: Since you have the shared components in another location, you may want to create a solution folder in MyProject and add the components that you are using to it. This will ensure they get pulled automatically when anyone loads your project from TFS - they won't have to go back and pull down the share components folder separately after discovering a build error.

Team Foundation Build Property for Build Folder

Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.

Managing common components with Fossil CVS

I'm a Fossil (and CVS configuration) novice attempting to create and manage a set of distributed Fossil repositories for a Delphi project.
I have the following directory tree on my development machine:
Projects
Some Project
Delphi Components
LookupListView
Some Client
Some Project For Client
Some Other Project For Client
Source Code
Project Resources
Project Database
I am setting up Fossil version control in order to version and share Projects\Some Client\Some Other Project For Client\Source Code, which contains Delphi 2010 source for a database project.
This project makes use of Projects\Delphi Components\LookupListView which is a Delphi component. I need this code to be included in the versioning system for my project. I will, in theory, need to include it in other Fossil repositories in the future, as well.
If I create my Fossil repository at the Source Code or Some Other Project For Client level, I cannot add any code above that level to my repository. What is the proper way to deal with this? The two solutions that occur to me are
1) Creating a separate repository for LookupListView and make sure that everyone who uses a repository for a project that references it "knows" that they must also get the current version of this project as well. This seems to defeat the purpose of being able to obtain a complete, current version of the project with a single checkout. The problem is magnified because there are other common component dependencies in this project.
2) Establishing my Fossil repository in the Projects directory, so I can check in files from various subfolders. This seems to me to involve an awful lot of extra path-typing when doing adds, and also to impose my directory structure (Some Client\Some Other Project For Client\Source) on the other users of the repository -- in this case, the actual client.
Any suggestions appreciated.
I use Git, but my approach can be applied in your situation.
I have one repository for all my components folder. This gives me an ability to get all of them with only few console commands (in case when I reinstall my OS or go to another computer etc.).
Also I have one repository per each of my projects. If some project uses 3rd party controls I create "components" sub-folder and do symbolic links (junctions) of every components set.
This approach have some disadvantages (when you "go back" in commits history of some project, components can be modified too. And if many projects are using same components this could cause some troubles). But I had no issues yet :)

Resources