It was brought to my attention that the files for downloading have become unavailable. I am working to move them to a new site and will have them up shortly. Sorry for the inconvenience.
[UPDATED - 10/19/2009] - FTP Server issue should now be resolved. Please email me if you have any difficulties, and I will reply with the files.
I recently took the plunge and decided to load Windows7 (pre-beta 6801) on my laptop. While I have been very satisfied with the performance and how stable it appears to be, it is not without its quirks.
The other day I restarted my machine, and before it got to the splash screen where it normally does the "ta-da" and displays the Windows Logo (immediately before ctrl+alt+delete screen) all I got was a black screen and a mouse. I tried all sorts of keystrokes and mouse movements, but I could not get the computer to respond. I tried "sleeping" the computer and even rebooting to the same event. I thought I was hosed. However, some stroke of genius occurred and, while at the black screen of horror, I disconnected my smart phone.
Ding, ding, ding, ding, ding...
That did the trick, my computer resumed the Windows dance and I was quickly able to login.
Now, I have rebooted several times successfully with my phone connected without a problem, but have had this rare occurrence happen to me more than once or twice. I would be curious if anyone else out there has experienced the same.
Recently I had the pleasure of migrating several VSS databases to Team Foundation Server 2008. One of the databases was pretty large (90k+ files) and took between 12 - 16 hours to migrate. However, about 6 hours in to the migration, I kept running across an error that would halt the migration process.
The error:
Could not find file 'C:\Conv\Tfs\<TeamProjectName>\blah\blah\somefile.txt'.
After searching and searching for a solution, I finally ran across this forum post that got me back on track again. While I cannot take credit for the solution, I would like to add some additional information.
Essentially, Visual Studio Team Foundation Server 2008 will not allow files that use the DOS 8.3 naming convention. For whatever reason, the VSS database had a reference to the file using the "fully qualified" name as well as the DOS 8.3 name.
During the migration process, VssConvert creates a database on the SQL Server, specified in your MigrationSettings.xml file, called VSStoVersionControlConverterDB. Within this database, there are about 4 tables, but the ones you need to pay attention to are SCMHistory and VerificationTable. Based on what I experienced, the SCMHistory table is populated when VssConvert begins scanning the VSS database for files. Once the migration piece is actually underway, the VerifcationTable is populated.
As the forum post indicates, you need to delete the file that is causing your error from both of these tables. What it doesn't say is how...
DECLARE @fileName VARCHAR(255)
SET @fileName = '$/VssRoot/blah/blah/somefi~1.txt'DELETE FROM SCMHistory WHERE ItemName = @fileName
DELETE FROM VerificationTable WHERE ItemName = @fileName
The only concern that I had was that I didn't want to fix this problem, rerun the migration, and have it fail again in another 8 hours because of some other @#$% file. While I had the opportunity, I tried a few more options.
At first, I figured I should just delete anything with a ~ in the filename, because that just isn't normal. :)
SELECT * FROM SCMHistory WHERE ItemName LIKE '%~%'
SELECT * FROM VerificationTable WHERE ItemName LIKE '%~%'
Fortunately, I ran SELECT statements first because, to my surprise, there were a ton of files that contained ~. Some of the files started with ~ and others were based on the DOS 8.3 format. However, not all of the files using DOS 8.3 format were raising errors as I had verified they migrated over successfully. I suppose the problem really only exists if a single file is stored in the VSS database in both formats. I did notice that the only time I got a migration error was when the DOS 8.3 file was in VerificationTable.
Ultimately, I decided to run this SQL script and it worked like a charm.
DELETE FROM SCMHistory
WHERE ItemName IN
(SELECT DISTINCT ItemName FROM VerificationTable
WHERE ItemName LIKE '%~%')
DELETE FROM VerificationTable
WHERE ItemName LIKE '%~%'
Of course, this is what worked for ME. You may encounter a different scenario, so be careful to see what you will be deleting before you delete it. Once you get the error, you should have the opportunity to do an incremental migration provided you didn't serialize your migration scripts. ;)
Also, assuming you want to incrementally migrate, you can open a connection to the VSStoVersionControlConverterDB within SQL and the migration will raise an error that the database could not be deleted. This will allow you to do some research on your files and prepare for what needs to be deleted during your next migration attempt.
NOTE: Depending on the number of files being converted, you may have to be very quick on the draw in order to delete your contaminated database records.
While attempting to deploy some SharePoint code via MSBuild, I ran in to the following problem.
I have a msbuild.proj that executes several stsadm commands. These work perfectly when executed from the command-line. However, once they are called from TeamBuild, I get "Access Denied" on the stsadm execution.
The TFS Service account is a member of the Administrators group on the build server. I can login to the build server as the TFS Service account and execute the command-line successfully. This problem only exists when the commands are spawned from TeamBuild.
I have also tried running several EXEC tasks using runas /trustlevel:unrestricted and various other options with no success.
After several, and far too many, hours attempting to resolve the problem myself, I burned a PSS with Microsoft to resolve this issue.
Here is what I had to do. Even though the TFS Service Account was a member of the Administrators group on the Build Server, I continually received Access Denied errors. The suspicion was that the TFS Service Account, when run from TeamBuild, was not executing as an interactive/desktop user. Therefore, there wasn't a profile that was being used. While I don't claim to fully understand why I was getting the errors, we did reach a solution.
I opened regedit and gave full control to the TFS Service Account for the following keys and their sub-keys. I would imagine Read Only access would work, but I have not explored further. Please let me know if you find anything else that may work.
I hate to admit that I have been plagued by this stupid BizTalk error for weeks now. I must say that I haven't been focusing on this particular issue the entire time, but when I did it wasn't pretty. I was never able to wrap my head around the problem, and even worse, the solution. Until...
The error:
MyOrchestration.odx(783,59): error CS1026: ) expected
MyOrchestration.odx(782,10): error CS1518: Expected class, delegate, enum, interface, or struct
I would receive this error only when a particular orchestration was included in my project. However, the orchestration that reports the error is not the one causing the error, but the first active orchestration in my directory. If I set the build action of the offending orchestration to none, the error would go away. I can say this with 100% certainty that this was the root of my problem as I tried all combinations of which orchestrations were included and found only one causing me grief.
Being the friendly error message that it was, I opened the orchestration using the Xml Editor and took a look under the hood. The line being referenced was the last line of the file. In other words, there was no code where the error was supposed to be. In the past, I had run in to cases where the generated C# code was corrupt, so I deleted all of that section and started over. Still, I got the same error. I even tried deleting that orchestration and starting from scratch. I finally was able to narrow it down to an error somewhere in my mapping and schema files. Further analysis showed me that the schema reference section was including some very strange data. Essentially, my source schema looked something like this:
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://schemas.companyname.com/projectname/FileType_FF" targetNamespace="http://schemas.companyname.com/projectname/FileType_FF" targetNamespace="http://schemas.companyname.com/projectname/FileType_FF" targetNamespace="http://schemas.companyname.com/projectname/FileType_FF" xmlns:xs="http://www.w3.org/2001/XMLSchema">
Since this schema was created using the Flat File Wizard, I'm not entirely certain how in the world this happened, but it sure did throw me for a loop. Especially because the error message had nothing to do with the actual error. Googling for the error message didn't return any helpful results. If you are one of the unlucky souls to receive this error, hopefully this will give you some assistance.
It's been quiet on the blogging front for awhile. Things have been pretty quiet at work and nothing of great value has been discovered. I have been playing with WPF and WCF a bit. I hooked up BTS 2006 to a WCF Send Port which was pretty cool. I didn't think the transport properties form was very "friendly". There were several values that were provided as drop-downs, but the drop-down boxes were empty. I had to go to the BTSNTSVC.exe.config file to determine the proper values. Once I got beyond that, I was rockin' and rollin'. I'm thinking of setting up a VM with R2 on it and playing with it a little more. I'll post my findings as they come. Other than that, I have really enjoyed playing with WPF and LINQ. Some very cool stuff, not what I am doing, but the technology. :)
I ran across a few things that I needed to update and have posted them here as well.
Notable changes include:
Link to readme.txt: readme.txt
Link to dll: BAJ.BizTalk.PipelineComponent.PGP.dll
Link to source code: PGP.zip
[UPDATED - 9/11/2007] - It was brought to my attention that I did not include instructions for obtaining the crypto.dll file. In my original post, I mentioned that you had to download the Bouncy Castle source code as I didn't feel it was appropriate for me to distribute it. Also, you will need to strongly name the assembly. I have updated the readme.txt file with the same message. Sorry for any confusion.
[UPDATED - 7/28/2009] - File locations have been updated and should be available for download.
