Add a Linked File in a Visual Studio Project: Add As Link

Yesterday I had to add a file into a database project as a link to another file. So not a copy of the file, but a link so I can use the file in multiple database projects and only have to maintain it once. Because I couldn't easily find the solution to this and I was searching on Google but also couldn't find it quick (enough to my opinion :)), I decided to write a short blog post.

I didn't know the exact naming of the property, so the majority of the links I got from Google where Linked Server items, only after changing the search phrase 3 or 4 times I found this entry by Grant Winney.

The normal icon that appears when you add a file is the following (at least when you don't have changes in source control, here TFS). A little blue lock is displayed, letting you know that it is a local file and it is checked-in in source control.

The other available icons would be:

A plus sign for a newly added file, not yet in source control:

A red check mark, for a changed file already in source control.

TL;DR - Solution

The trick to add a file as a link is not in the menu options in Visual Studio itself, that's also where I started searching.

You have to first add an existing item to your desired folder, as shown below.

After selecting the file, don't click Add, but click the dropdown next to the Add button. There you can select Add As Link.

Et voilá, we've got ourselves a linked item, with the new icon that looks like a hyperlink :)

Let me know if you have any remarks and found this post useful in the comments!

Nicky

What to do when SVN cleanup fails

I ran into an issue with TortoiseSVN earlier this week, where the regular cleanup didn't finish correctly anymore, so I had to resort to other methods. Searching for a solution I came up with several possible solutions.

Found at StackOverflow:

1. Delete the .svn directory for your working copy.
2. Start a new checkout in a new, temporary directory.
3. Cancel the checkout (we don't want to wait for everything to get pulled down).
4. Run a cleanup on this cancelled checkout.
5. Now we have a new .svn directory with a clean database (although no/few files)
6. Copy this .svn into your old, corrupted working directory.
7. Run svn update and it should bring your new partial .svn directory up to speed with your old working directory.

That's all a little confusing, process wise. Essentially, what we're doing is deleting the corrupt .svn then creating a new .svn for the same checkout path. We then move this new .svn to our old working directory and update it to the repository.

However, this morning the above solution also didn't work and I resorted to the following steps (a similar solution found at SO):

1. Move the affected subdirectory out of the working copy. Move it somewhere else so it becomes invisible to SVN
2. SVN cleanup at the root
3. SVN update, which will recreate a clean subdirectory, with all the correct permissions.
4. Manually merge any changes to the subdirectory's files (copy the files affected) from the previously moved version. Do NOT copy back in any of the .svn control area.