I'd like to use visual studio to store in source control xml files coming from a server.
I have a request like http://server/query.aspx?FILE_ID=1234 that allows me to download an xml file. Those file are part of our development activities, that's why I'm looking for a convenient way of integrating those file in source control.
I'd like to have a project containing all the xml files I want to check-in in source control and add a pre-build command allowing to download the files, but I did not find any convenient way of doing it.
People have a tendency to forgetting to do it manually, and we have already seen all the possible scenarios: lost files, released version without the ability to know the exact configuration used, ... I'd like to automated this step so that it does not happen again in the future.
I'm sure there is a simple and smart solution, but I could not find it. Any suggestion would be appreciated.
You should be able to use wget in a pre-build action to fetch the latest version of the files. I can't think of a reason why that wouldn't work.
Personally i would consider finding a way to automatically commit those files to source control whenever they change on the server. I've never used tfs, but I assume there is a commandline-client which allows you to commit files in a scripted way. If you don't have any control over when the files change you could do this every N minutes on a machine which is always on.
You can write a (powershell) script that does the fetching, and checkin of the file before your build starts. That's how we fetch external assemblies to be included in our build.
To get you started, take a look at these powershell functions for TFS interaction:
http://www.brokenwire.net/bw/Programming/73/ (TFS 2008)
Related
I would like to create a mechanism by which I automatically submit the executable corresponding to the updated code. My development environment is Visual Studio 2005 and I use the windows GUI client to submit changes.
Ideally, I would like to ensure latest binary is submitted in the same change list as the code changes.
My requirements are:
The code should be recompiled and binary should be checked out when source code dependencies change.
Related documentation / non-source files do not affect binary
Perforce should complain when sources are changed and submitted but the binary isn't included in the change list.
How could I enforce these rules? Is it possible to create a P4 script that runs before each submission? Also, is it possible to write a Visual Studio script that automatically checks out the executable before compiling?
Thanks,
Shahar
I think you can accomplish most of this without too much work.
If you include the output directories in your Perforce workspace, you can easily just check them in every time you do a build. (You might want to talk to the Perforce admin about using a 'purge' option so you're not storing thousands of copies of binaries.) You can use a trigger to make sure that source code in certain directories is always submitted with a binary.
I am using PowerShell to modify a series of configuration files within a solution. The solution is under TFS 2010 control.
The solution has many projects and the configuration files are all xml files. The easy part is if I just need to modify a file, I check it out using the checkout command then save the file when I'm done. All good. I go into Visual Studio and see the modified files are updated with pending changes as I would expect
The part I'm having difficulty with is when I have a configuration file that is no longer needed and can be deleted. Using the delete command does, in fact, mark the file for a pending delete, but it does not modify the project file where the deleted file is contained.
When I delete a file via Visual Studio, it automatically checks out and modifies the project file for me. I'm not getting the same result when using a command line delete.
It's not practical for me to do this by hand as I am eliminating over 1,000 files.
Any help would be greatly appreciated!
Thank you.
There are two components at work here. When you are running inside VS, the project system processes all file commands (adds, deletes, edits, etc.) and then calls into the TFS Object Model to actually pend the changes in TFS. The project system is also the one responsible here for removing the reference from the project file. The TFS OM has no knowledge of whether a file is part of a project or not when it is run outside of Visual Studio.
If you have a list of the xml files that you need to delete your best bet is to write a script that reads these in and removes them from the project file (after pending an edit on the project file, of course).
-Taylor,
TFS Version Control Development Lead
Thank you all for your responses. After much digging and trial and error, I figured it out. It was way more simple than I was making it.
In short, I used DTE and ran my script from within VS using the PowerShell console. It went something like this:
$mySolution = $dte.Solution
$projectItem = $mySolution.FindProjectItem($fileToRemove)
if ( $projectItem -ne $null )
{
$projectItem.Remove()
}
Executing the Remove() command on the ProjectItem checks out the corresponding project and edits it accordingly.
Again, thank you again for the time you all took to look at my question and respond. Hope this helps someone else someday!
I'm in the process of adding a WIX project to my solution and I'm using HEAT to create the files list. I've been having trouble getting builds to work unless the files list(wxs) is checked out.
I came across this tutorial and it says:
"If you have source control you have to include the FilesFragment.wxs
into your project but remove its source control binding. "
Is this possible in TFS 2010 with VS2010?
Click/Select on the file.
In VS, go File Menu / Source Control / Exclude file from source control.
This method only allows you to do this one file at a time.
The file will still be in your project and will not be under source control.
I don't like dynamically emitting installation authoring at build time for abouta dozen reasons but if you really are going to do it, perhaps you should consider checking it out and checking it in so that you have some histroy of what actually happened from build to build.
Otherwise if your installation behavior changes from one build to another build in an unexpected and undesirable way, you really aren't going to have any tracability other then diffing MSI's as to what went wrong.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
Most of the time I am doing several distinct developments on the same project and, in order to have some logical separation between them, I use a personal version control system on a project (namely fossil but this is mabye too much detail).
This allows me to commit my work in different branches in order to merge them afterwards. Meanwhile I maintain a trunk branch in which I commit work by coworkers.
But when I switch from a branch to another one (in order to perform some merge action for instance) and go back to where I came from, Visual studio will detect timestamp modifications and rebuild files that have not really be modified.
Is there a way to ask Visual Studio to consider that a source file has changed when only some hash of its contents has changed?
As the answer seems to be “no” here is another way of achieving what I would like, for which I am starting a bounty. Still read the above please.
Do you know of a simple way to have a snapshot of the timestamps and MD5 hashes of my source files, and then, for every file of which the timestamp changed, compare MD5 and rollback timestamp modification if MD5 has not changed?
Thank you for your answers.
I'm afraid this is not really possible.
The issue here is that this is not just a thing for VS but actually for the entire build system which is quite separate from the actual IDE.
In order to decide if and .obj should be compiled, VS compares its timestamp to that of the source file. Doing what you suggest will require the .obj file to include the MD5 of the file. This also goes for .exe and .dll files. Changing the binary format of these files and unlikely to happen for such a rarely needed feature.
Edit - I take it back, this is probably is possible in theory. One way to go is to write a VS plugin. The plugin would save the MD5s to some file in the output directory and the just before the build starts will update the modified dates of the appropriate files.
Thinking further, this might be possible using a pre-build step..?
A simple workaround may be to write a script which looks at a file that Visual Studio isn't aware of and, if it has changed, copies it to overwrite the file that Visual Studio is aware of. The file Visual Studio sees is then excluded from source control, so it's timestamps shouldn't get touched.
The copying decision might be based on a hash, but it could just as easily compare the source and destination files directly.
Visual Studio definitely has the ability to include code generators in the build - which is what this script would be, in Visual Studios eyes. I don't know the details though - I get cmake to manage these things for me.