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.
Related
We have a nopCommerce website of a client's that one of their IT guys was modifying views directly on the web server. They now want to do more extensive changes so we want to put the baseline NopCom code in TFS.
Then, ideally, we'd like to be able to identify all the views that were changed directly on the web server and have those changed views be recognize as changes in TFS source control to check-in.
Is there anyway to do this in Visual Studio/TFS in batch? i.e. it would be great to do a check-in locally so all the base code of NopCom was checked in to TFS, then download the website files and overwrite them in the local workspace and have TFS recursively do a diff and determine if any new files were added or existing ones changed and mark those for check-in.... I know...I'm probably dreaming, but any other smart workarounds appreciated as well, assuming this won't work.
TFS does what you want. To set up Team Foundation Version Control (TFVC) on your dev machine, you just need to create a workspace and then add your code. Check link: https://www.visualstudio.com/en-us/docs/tfvc/set-up-team-foundation-version-control-your-dev-machine
When your codebase is under version control, you can develop your app, create and open files in Solution Explorer and write your code, while version control does other work for you. When you check files in and out, it keeps track of your changes and creates a history of your project.
You can use the Diff window to clearly see the difference by comparing folders or files. You can compare server folders and local folders to each other, and view the differences between the contents of each folder. You can compare two server files, two local files, or a server file against a local file and view the differences between the files.
You can get more details about TFVC from website below: https://www.visualstudio.com/en-us/docs/tfvc/overview
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
The MSDN documentation lists four options, with limited explanation:
Overwrite "Overwrite existing writable files if they conflict with the downloaded files." Does this apply to all files, or just ones we've told TFS we've edited?
GetAll "Gets all files." What files does TFS not normally get?
Preview "Executes a get without modifying the disk." This one seems pretty clear.
Remap "Remaps existing items on the disk to the server items where the content and disk location are not changing." I have no idea what this means.
Overwrite: will blindly overwrite writable files that you have not pended for edit. If you have marked a file as 'writable' then you have violated the contract with TFS and it assumes that you have done this for a good reason (eg, modifying the file without taking a checkout, because you were working offline). This will generally produce a writable conflict on the file, but if you specify this flag, then the writable file will be overwritten.
This only applies to server workspaces (local workspaces are always writable). This has no effect on files that you have pended for edit. Get will always produce conflicts for files that are edited locally and updated on the server; if you want to update files that are checked out, you must undo the checkout (or resolve the conflict with TakeTheirs).
Get All: will download every file and update it, even if TFS believes that the local version is the same as the remote version and that downloading a new version would be a noop. TFS tracks every version that you have locally, as well as remotely, so this is only useful if you edit files locally without checking them out.
If you have kept them writable, then then - as mentioned above - this will be a writable conflict. If you have then marked them read-only then TFS assumes that you have not made any changes and will not bother updating them when you do a get (because it knows the file contents haven't changed). If you have manually changed the file contents, then marking this will update those files to the server version.
Preview: will just fire events and provide results that indicate what would be downloaded with the given parameters.
Remap: is a clever option that allows you to perform an in-place branch switching (which is very common with some version control systems that branch at the repository level - like Git - but somewhat complicated in TFVC.)
Consider that you have mapped $/Foo/main to C:\Foo, and done a get latest. If you update your working folder mappings so that $/Foo/branches/feature now points to C:\Foo, then issue a get with Remap, then the server will download only the changed files between main and branches/feature, so it's an inexpensive way to update your local workspace to a feature branch.
(If you're looking for an example, this functionality exists in the command-line interface and in Team Explorer Everywhere but not in Visual Studio.)
Had to change my computername and domain. Now I can't access team foundation. I tried this statement to fix it.
tf workspaces /updateComputerName:MyOldComputerName /s:"http://MyServer/MyCollection"
It didn't work. I get the following error "Key not valid for use in specified state."
Not sure what to do now.
It sounds like you may have a problem that will prevent remapping the workspace. However, it's possible that the command isn't quite correctly formed, so try checking the collection URL (I'd expect it to include MyServer:8080), and in versions of TFS 2010 onwards the documentation refers to /collection: rather than /s:
If that fails, then one approach to rescue things is to create a new workspace and delete the old one. You can transfer any edited files you had checked out to the new workspace as follows:
Rename your old source code folder, so you keep a backup
Create a new workspace that maps the (old) source code folder location, and Get the latest version of the code.
If you think you deleted or added files, use a folder-diff utility to find them, and manually re-do those changes.
Now check out everything (right click on the root folder and check it out)
Copy your backed up source code over your workspace folder
Undo checkout on everything. Visual Studio will ask if you want to discard your changes. Carefully choose the "No to all" option. This means it will only discard locks on unchanged files.
You will now have all changed files listed in your pending changes.
Once you're absolutely sure this has all worked, you can delete your backup of the source.
(You can achieve a similar thing by unplugging your network cable to force Visual Studio to go offline, moving your old source code back in place of your new workspace folder, then plug the net cable back in and using File > Source Control > Go Online. This should diff your code to the server and work out what changed. I don't trust this as much as the above approach though)
Once you have the code in your new workspace, you can use the tf command to delete the old workspace to clean everything up.
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…