Can anyone think of a way (perhaps using a PowerShell script or similar) where I can look for *.cs files that are on disk in the folder structure, but aren't included in a project file?
This has come about gradually over time with merging in Subversion etc. I'm looking for a way to clean up after myself, basically. :)
All your .cs files will be mentioned in the project file, right? Scrape the XML, list the files and then do a search on the whole system. Works, but is inefficient.
"Show all files" button at the top of Solution Explorer, then manually inspect?
The PowerShell script in my other post will do this. The script will get the list of included files from the project file and compare that against the files on disk. You will get the set of files that are on disk but not included in the project. You can either delete them or pend them as deletes in TFS.
The script is here: https://stackoverflow.com/a/23420956/846428
Related
I need to include all the output from some of the programs projects in the installer... my question is similar to the one in this post: How to add a whole directory or project output to WiX package
However, I am afraid I don't really understand the answer given in this link. From all the reading I have done, I think I need to use Paraffin to do this. But is there a "start from the very beginning, how-to" resource for using paraffin?
I have read this page: http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx
and one of the posts mentions calling paraffin from a bat file. Is this how one would "use paraffin" in their installer? If it makes a difference, I have been using Visual Studio to work on this project, and am also not sure how to use command line from within Visual Studio. Does anyone have any resources for a very new beginner? Thanks.
I ended up including each .dll and .exe manually, since they don't change very often. It was fairly easy to format them in this style:
`<File Id="WhateverId" Name="NameToDisplayAfterInstall" Source="$(var.ProjectName.TargetDir)Filename.ext" />`
I used Excel to format a list of files quickly and easily. I put all of these File tags in the <DirectoryRef Id="INSTALLLOCATION">
tag.
I did figure out how to scrape all the dlls and exes from the project output by using Heat (not paraffin) and harvesting a directory, not a project. Harvesting a project yields only the main exe and dlls. The problem with harvesting a directory, at least in my case, is that I ended up with a lot of excess files, (like .pdb and .xml) that I didn't want.
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!
We just started using TFS and it works great. I have one question though, if we delete a folder it's not deleted on my local workspace. We are currently reorganizing a project and I wish to not have heaps of unused folders on my local drive.
Where can I configure this?
Thanks in advance.
In you have the Visual Studio Power Tools (http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f) you can use the command line tools tfpt to clean up all your workspaces.
In a shell window
change directory to your workspace root
type \tfpt.exe treeclean /recurse .
This will remove any file or folder not in source control.
Another solution, which also checks how well your project is put together, is to cut the whole folder and move it elsewhere, then perform a get across the project. This will allow you to check if the project will build or if there are some "magic" DLLs missing. Anything that is missing can be retrieved from the copy of the structure and added into source control.
In my C# client application, I use XSLT to transform XML into HTML.
I would like to be able to edit these files in place, without having to recompile the entire solution. I'm having trouble working out how to set up Visual Studio 2008 to allow this.
The problem is that the XSLT files must get copied to the output directory somehow. Currently this happens during the build process. (My XSLT files are set to "copy if newer".) The build process can take a few minutes, which seems excessive for making small tweaks to the HTML.
I could make my XSLT edits in the output directory itself, but the output directory is not under source control. I have accidentally wiped out my quick edits several times by building my solution.
I'd like to reduce the cycle time for debugging XSLT, while keeping my XSLT files under source control and preventing accidental overwrites.
Summary of Responses: It appears that the most practical approach for solving this problem -- given that Visual Studio doesn't have a nice way of doing it out of the box -- is to create a separate project that contains the content files. These files get copied to the output location when the project gets built. That way I don't have to compile the whole solution, just the one project with all the static information like XSLT, CSS, images, etc.
Several folks suggested using sync or batch copy tools, but while this would work for me personally, setting it up for the other members of the team too would be a lot of extra work.
I am not entirely clear about your question, but you can instruct Visual Studio to copy the file from the solution to the output folder every time that you build.
Let me try to understand your scenario:
You have the XSLT files checked into source control along with your C# code. For example, if your project is in a folder called MyProj, then the XSLT files reside in MyProj/Templates
You want to be able to edit the xslt files in the Templates folder and submit those changes to source control just like you do with .cs or other files in your project.
You want a copy of your xslt files in the bin/Debug or bin/Release folder along with your executable.
If that is the case, add the XSLT files to your Visual Studio project. Then right click on them, open Properties, and set "Build Action" = "Content" and "Copy to Output Directory" = "Always". Whenever you build your project, the latest copy of the XSLT files will be placed in your bin/Debug or bin/Release directory.
One approach is to include a C# Preprocessor Directive to point my XSLT load function to the solution directory when in debug mode, but the output directory when doing a release build.
Something like:
string viewFolder = AppDomain.CurrentDomain.BaseDirectory;
#if DEBUG
// Move up from /bin/debug
viewFolder = viewFolder + #"..\..\";
#endif
But that feels like a hack.
Apparently you're managing two concerns in one project. The first concern is your business logic (instantiating an XSLT transform, calling it to transform some XML content, outputting the HTML result....). The second concern is the Transformation itself.
So why not create a separate project for your xslt sheets? "Building" this project would consist of copying the sheets to the output folder. Changing xslt will not influence the other project, hence reduce the build time.
Separation of Concerns at project level, that is :)
You can edit the file directly in the output folder.
On another note, a lot of people don't know that rich tools are built into VS to allow debugging xslts.
http://msdn.microsoft.com/en-us/library/ms255605(VS.80).aspx
One solution that might work for you is to setup a junction to your Templates in your output folder. This would allow you to use the XSLTs directly without copying them to the output folder. A good idea is to ensure (create) the junction as a build action.
Prerequisites:
NTFS
A tool to create junctions (e.g. junction)
Create a batch file that copies your xslt's from their source-controlled location to all your bin directories (bin/debug bin/release or whatever ones you have defined)
Add the batch file as an External Tool, optionally assigning a keystroke (or chord) to execute the batch file
Edit, run tool (I'd assign a keystroke to this to make this easy), then check your webpage.
Could you use a file synchronization program (e.g. Microsoft SyncToy "is a free application that synchronizes files and folders between locations") to copy the files? This would allow you to avoid the "copy on build" step because the files are automatically copied after saved. Also, if you edited them in the output directory, the changes could be copied back into your source controled directory. Not what the best real time sync program is for this scenario is, but that could be another question.
I have exactly the same issue. I have bought a program called ViceVersa (http://www.tgrmn.com/) in which I have setup sync profiles so that my css, layout and xslt folders are synced from my machine to my dev server as soon as any changes are made. If I make any code changes then I just publish as normal.
I understand this is an older post but I found a different solution to basically the same problem.
Visual Studio allows you to 'link' files.
Right click on the folder in the solution where you want the file link to be located.
Click
'Add'
'Existing Item..'
(select the file)
Go the 'Add' Drop down and select 'Add as Link'
I have a Visual Studio (2008) project where I have some files added as links (through Add Existing Item->Add As Link). Suppose I want to copy this project somewhere else (give it to another developer, release source code, etc.) and I would like to "convert" all these links to actual copies of these files. Is this possible? How can I do this in VS or is there some 3rd party utility to do that?
Thanks.
I met this exactly problem, and wrote a little tool to do this.
Checkout: http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.cnblogs.com%2Fdeerchao%2Farchive%2F2010%2F04%2F22%2F1718183.html&sl=zh-CN&tl=en
I would guess that the easiest approach is simply to remove the items from your project and then add them again, but not as links? If you want to keep the files as links in your project, make the copy first and then remove/add the items in the copy.
if all your files are under a single root (and not c:\...) and relative you can try use TreeTrim.
treetrim.console c:\ -workingcopy -zip:writeTo:c:\out.zip
this will create a zip will all the need info without the temporary files (.pdb, .ncb)