I'm using the TFS 2010 SDK to programmatically check in edits to files into TFS 2010. The documentation on the TFS 2010 SDK is sparse at best. When I call the method workspace.pendedit() passing in an array of files I want to mark as having a pending edit, nothing is actually checked out. So when I call workspace.checkin() passing in workspace.getpendingchanges and some comments I get an exception that there must be at least one thing that has a pending change (which should be what I passed into pendedit). Any thoughts on why the app isn't marking the files as having a pending edit in the workspace?
Make sure you're doing everything in the right order so TFS knows that the file has changed. You have to:
Get the file from the workspace first.
Pend the edit
Make the changes to the file
Check in the workspace.
Example:
GetStatus status = workspace.Get(new GetRequest(migrationPath, RecursionType.None,
VersionSpec.Latest),GetOptions.Overwrite);
workspace.PendEdit(migrationPath);
checkInAuthor = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
It turned out that even though I had added the files and checked in the files, it seemed that the workspace didn't recognize that the files were there, and as a result I had to do a Get() prior to the PendEdit()
Related
I was working on a solution and under the assumption that I had already checked in my changes, I pulled down a new version of the solution and all the changes disappeared.
One of my colleagues suggested that as I often ran it in debug mode that there might be a dll kicking about that I can reverse engineer but dlls all seem to have overwritten too.
This is about 2 weeks worth of work so any help would be appreciated.
If you didn't shelve or check in the changes before the overwritten, I'am afraid you'll not be able to revert the file.
However when you edit the files in local, the changes will be temporarily saved to the TFS temporary diff files in "C:\Users\{user}\AppData\Local\Temp\TFSTemp". The files all have names like "vctmp38604_939733.cs". You can get the changes from them.
So, you can have a check for the folder, hopefully the diff files still there.
Just a suggestion: please ALWAYS shelve or check in code in time in case missing the changes.
So, I have a WIX project which is to install either fresh installations or over previous installations of a product. This product, if it was already installed, has several files inside of 3 different folders which need to be preserved. This project also needs to copy the contents of those 3 different folders into another set of folders (same content in two different locations). In order to accomplish this I have set up my project to first attempt to write into the original folders if the files don't already exist, then copy the contents of those folders. On an upgrade where those files already exist this works fine. On a fresh install the second set of folders do not get created, but all the files do.
My assumption, and I may be incorrect, is that the msi is attempting to copy the folders over before they have even been created. This would cause folders to not exist in the area they were supposed to be copied to as there would be nothing to copy from. Is there a way I can ensure the files have been generated before trying to copy them? Is there a better way of going about this that I'm not seeing?
EDIT:
I'm going to try to clear this up a little. What I'm trying to do is the following (pseudo):
1) See if an option file (hi.opt) exists in c:\options, if not create it.
2) Copy that file to c:\options\opt2015.
I'm doing this 3 times for 3 different folders. I am creating the initial files with Wix in the c:\options folder using the NeverOverwrite parameter. This part works great; the files are created without issue and none are overwritten if they already exist. Where the problem lies is step two where I'm using the CopyFile Wix command. This will only copy some of the files from the c:\options folder to the c:\options\opt2015 folder. Depending on the initial setup of the system (if the files at c:\options exist or not) some files will copy over and others won't. It's not random, the results are repeatable every time, but there seems to be no reason why some files copy and others don't depending on the initial setup of the system.
I hope this makes sense and is a little more clear, though I think it makes things worse! It is strange behavior because to me it looks like everything should just work, but it doesn't (isn't that every bug though).
Edit2:
After more work and creating a vb script which runs perfectly outside of WIX my team and I have determined that the files just are not being seen by WIX during the installation even though they do exist. We haven't found any permissions issues and the installation is running as admin on an admin account. Doing the copy via a VBS or through the Wix CopyFile command results in, well the same results; files that already exist on the system are not being copied. Any more ideas? Should we find a solution I'll be sure to post it because this is just getting weird.
I believe your installer design should work as long as you're attempting to copy the files after the InstallFiles action runs. You should be copying the files from the first set of folders to the second set of folders by doing one of the following:
Running a deferred custom action that executes after InstallFiles
Using the MoveFiles action
This is too long for a comment, but may not be an answer either....
There isn't really such a thing as "over previous installations of a product", especially if you end up with multiple instances in Programs/Features, and files that may or may not have the same component ids replacing each other - that's going to be a mess. If you need to upgrade the installed product, use a major upgrade, that seems to be where you're going with this. If you are already writing custom actions to do some of this "first attempt to write into the original folders" then I've no idea what's going on or where you doing this in the install. In general, if you need those files in the new install then add them to the new major upgrade MSI. If you need to copy the older existing files from the older product, then do a major upgrade with afterInstallExecute and write custom action code to copy them before the InstallFiles action. Or the CopyFile WiX element could do it, see the part about the element under a component with no fileid.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
Well, as sometimes happens, the error was entirely elsewhere. It turns out that an uninstaller for another program which was in the chain of programs which are installed at the same time was destroying the folder. Unfortunately this is what happens when a product isn't touched for 10 years. Thank you for your contributions, they were very helpful. Even though I was going down the wrong path the whole time I still made use of them in my tests and am more adamant about checking the installation order.
This post asks the same question, but the answer is to use the new template that already makes use of the NugetRestore activity.
I tried to use the new template (TfvcTemplate.12.xaml) on a sample project and couldn't begin to get it to work. I suspect its a rights issue somewhere (can't access the template during the build), but I couldn't solve it. Edit: got a copy of that template and it still doesn't seem to call nuget; same problem - I need to make the NuGetRestore activity work.
In any case I have customizations already in place and only need to add in the new activity.
The problem is the activity has a "Solutions" string array property and I don't know how to pass the path to my solution. If I pass {"$(SolutionRoot)\MySolution.sln"}, I see that unexpanded literal in the log:
c:\Program Files\Microsoft Team Foundation Server 12.0\Tools\nuget.exe restore "$(SolutionRoot)\MySolution.sln" -NonInteractive
What can I pass as my solution path?
I am using Visual Web Developer 2010 Express and I just added my files into Visual SourceSafe. When I try to save files in Visual Web Developer, it says, "The file cannot be saved because it is write-protected." It gives me the option to overwrite, but I don't know if that's how it's supposed to work. Ideally, I will click save and it will save the various versions into source safe. I've never used source safe before; my previous source-control system just enabled be to click "commit."
Files under source control are marked as read-only to prevent accidental changes to files and only made writeable when you check them out for editing.
Because there is no source control integration with the Visual Studio Express 2010 editions when you make an edit the file is not automatically checked out from source control so it remains read-only, thus causing the problem you have here.
You either need to check out the files before editing the project or force an overwrite and then check out the file after the event. Neither of which is an ideal solution.
When you add items to source control, such a Source Safe, it marks them as Read Only to ensure they are not written by anyone who has not checked-out the files.
You need to check-out the file you wish to edit, then edit it, save it, then check it back in.
Source Safe is rather old and not really maintained by Microsoft anymore - consider using something more modern like Subversion or Git.
I'm trying to use the VssGet task of the MSBuild Community Tasks, and the error message "File or project not found" is beating me with a stick. I can't figure out what in particular the error message is referring to. Here's the task:
<LocalFilePath Include="C:\Documents and Settings\michaelc\My Documents\Visual Studio 2005\Projects\Astronom\Astronom.sln" />
<VssGet DatabasePath="\\ofmapoly003\Individual\michaelc\VSS\Astronom_VSS\srcsafe.ini"
Path="$/Astronom_VSS"
LocalPath="#(LocalFilePath)"
UserName="build" Password="build"
Recursive="True" />
If I write a Streamreader to read to either the database path or the local path, it succeeds fine. So the path to everything appears to be accessible. Any ideas?
Two thoughts. One, sometimes a type load exception manifests as a FNF - let's hope that's not it. But if the code is actually being honest, you can track the problem using Procmon or Filemon. Start one of those utilities and then run your task again. You should be able to track down a record of a file that couldn't be located.
#famoushamsandwich that's a great response -- I had not previously heard of procmon or filemon. Tried procmon on the problem, but even after sifting through the relevant output (my gosh the machine does a lot more stuff behind the screen than I was aware of) I couldn't find where a file I'm referencing wasn't being found.
Procmon and Filemon are good suggestions - just make sure you filter the results to only show errors. Otherwise the success messages will bury the problem entries. Also, you can filter out processes that are not at fault (either through the filter dialog or by right-clicking the entry and choosing "Exclude Process".)
A couple other thoughts:
In the LocalFilePath, you are specifying a single file as opposed to a folder. The task, on the other hand, specifies to get files recursively. Perhaps you need to remove "\Astronom.sln" from the LocalFilePath?
Is the build task being run under your account or another? It's possible you have a permissions issue
Do you already have a copy of the code pulled down in the same location? Perhaps there is a failure to overwrite an existing file/folder?