This is really just a note to self.
Enter wmic qfe list full /format:htable >C:\hotfixes.htm on the command line.
Tuesday, March 31, 2009
Wednesday, February 25, 2009
Error while installing Systems Management Server 2003 Service Pack 3 on Windows Vista
I hope that this saves someone some time.
If your attempt to install SMS SP3 on Windows Vista fails with the message "not enough storage to process this command" then follow the steps enumerated in this support article.
If your attempt to install SMS SP3 on Windows Vista fails with the message "not enough storage to process this command" then follow the steps enumerated in this support article.
Monday, January 12, 2009
FreeNAS Server
Built a network-attached storage server using FreeNAS and a Dell OptiPlex 280 based on this guide from Maximum PC. Setup was unbelievably easy and the machine works great. The only problem I ran into was creating my shares. This post helped me understand the configuration required.
Friday, January 2, 2009
Editing multiple VS2008 solution files with PowerShell
Our huge LOB application is comprised of 30+ Visual Studio 2008 projects. One of these projects, which I'll call the 'Framework', is used as a reference by many of the projects. We use several different solution files comprised of a subset of the 30+ projects in order to improve Visual Studio performance as well as reduce Solution Explorer visual clutter.
I recently needed to move the Framework project to a new location in Team Foundation Version Control (TFVC). This move meant that some of the solution files needed to be altered because the TFVC references inside the file would now be invalid. Specifically, the SccProjectNameNN reference needed to be altered, where NN is the ordinal value of the project reference in the solution file.
Doing this in Visual Studio would be extremely tedious because each solution file would have to be opened, remove the invalid Framework project(which would also cause the reference to be automatically removed from the other projects in the solution), add the valid Framework project reference back to the solution, and add the Framework project reference back to each affected project. Time was also a factor. I didn't want to hold up developers by having solution and project files checked out. We allow shared checkouts, but I was concerned about developer TFS workspaces if I made any mistakes.
Recently I had used Powershell to alter reference paths in a Visual Studio project file. Could I do the same with the solution files? (Hint: Yes, I could.)
PS H:\> $projectLocation = "C:\Workspace"
PS H:\> $files = get-childitem $projectLocation -include *.*sln -recurse
| Select-String -pattern "/OldVersionControl" -SimpleMatch
| Select-Object -Property Path
PS H:\> $files | Foreach-Object { CheckOutTfsFile( $_.Path) }
PS H:\> $match = "/OldVersionControl"
PS H:\> $replacement = "/NewVersionControl"
PS H:\> $files
| Foreach-Object { (Get-Content -Path $_.Path -encoding UTF8 )
-replace $match, $replacement | Set-Content $_.Path -encoding UTF8 }
As you can see there's no real magic here- just a simple replace operation inside each file that has content that matches '/OldVersionControl'. The pipeline allowed me to avoid the dreaded manual tediousness of updating multiple solution files.
I recently needed to move the Framework project to a new location in Team Foundation Version Control (TFVC). This move meant that some of the solution files needed to be altered because the TFVC references inside the file would now be invalid. Specifically, the SccProjectNameNN reference needed to be altered, where NN is the ordinal value of the project reference in the solution file.
Doing this in Visual Studio would be extremely tedious because each solution file would have to be opened, remove the invalid Framework project(which would also cause the reference to be automatically removed from the other projects in the solution), add the valid Framework project reference back to the solution, and add the Framework project reference back to each affected project. Time was also a factor. I didn't want to hold up developers by having solution and project files checked out. We allow shared checkouts, but I was concerned about developer TFS workspaces if I made any mistakes.
Recently I had used Powershell to alter reference paths in a Visual Studio project file. Could I do the same with the solution files? (Hint: Yes, I could.)
PS H:\> $projectLocation = "C:\Workspace"
PS H:\> $files = get-childitem $projectLocation -include *.*sln -recurse
| Select-String -pattern "/OldVersionControl" -SimpleMatch
| Select-Object -Property Path
PS H:\> $files | Foreach-Object { CheckOutTfsFile( $_.Path) }
PS H:\> $match = "/OldVersionControl"
PS H:\> $replacement = "/NewVersionControl"
PS H:\> $files
| Foreach-Object { (Get-Content -Path $_.Path -encoding UTF8 )
-replace $match, $replacement | Set-Content $_.Path -encoding UTF8 }
As you can see there's no real magic here- just a simple replace operation inside each file that has content that matches '/OldVersionControl'. The pipeline allowed me to avoid the dreaded manual tediousness of updating multiple solution files.
Wednesday, December 10, 2008
Vista x64
A new Dell Latitude E6500 with Vista x64 installed appeared in my office the other day. Its 4GB of RAM makes it a capable machine, but its black finish seems to attract dust and fingerprints. I'm always wiping it with my shirtsleeve to retain that shiny, brand-new look.
One of our applications exhibits unusual behavior when running on it. This application uses the 32-bit Oracle Data Provider. We've got several builds of this application available at any given time. Builds compiled with a 'Release' configuration have no problems. 'Debug' builds are a different matter. Certain 'modules', which are actually dynamically loaded assemblies, don't load at all. Examination of the Event Log reveals that BadImageFormatExceptions are being thrown from the Oracle.DataAccess assembly. This is mysterious because all of the modules use this assembly so I would think that none of them would load. This requires more investigation. There are some workarounds for this condition but I haven't had the time to yet implement them. I don't want to alter my OS setup so drastically that it dramatically differs from end-users' machines. Then again, none of the users are going to be running Vista x64.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
I hope that Vista x64 will play nicer with Visual Studio 2008. Currently, VS2008 crashes when I return to the office in the morning if I leave it running overnight on my XP Pro machine.
One of our applications exhibits unusual behavior when running on it. This application uses the 32-bit Oracle Data Provider. We've got several builds of this application available at any given time. Builds compiled with a 'Release' configuration have no problems. 'Debug' builds are a different matter. Certain 'modules', which are actually dynamically loaded assemblies, don't load at all. Examination of the Event Log reveals that BadImageFormatExceptions are being thrown from the Oracle.DataAccess assembly. This is mysterious because all of the modules use this assembly so I would think that none of them would load. This requires more investigation. There are some workarounds for this condition but I haven't had the time to yet implement them. I don't want to alter my OS setup so drastically that it dramatically differs from end-users' machines. Then again, none of the users are going to be running Vista x64.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
I hope that Vista x64 will play nicer with Visual Studio 2008. Currently, VS2008 crashes when I return to the office in the morning if I leave it running overnight on my XP Pro machine.
Thursday, October 9, 2008
Editing multiple VS2008 project files with PowerShell
I recently needed to change reference paths for multiple project files in a solution. In the past I had done this manually, which was inefficient and frustrating. It occurred to me that PowerShell would alleviate the tediousness of this task.
Did I mention that the project files were under TFS version control? I created the following helper function to check out the files. I didn't create a corresponding function to check in the files because I wanted to eyeball them before check-in.
function CheckOutTfsFile([string] $FilePath)
{
Write-Host("Attempting to check out " + $FilePath)
$tfsvc = Get-TFSVersionControl
$ws = $tfsvc.GetWorkspace((Get-Item $FilePath).DirectoryName)
$ws.PendEdit($FilePath)
}
So here's the actual code. I needed to alter part of the path to the 'Common' project in 30+ Visual Studio 2008 project files. Specifically, I needed to change every instance of 'Common\Main' to 'Common\Production\2.4.0.0' to support a source code branch.
PS H:\> $projectLocation = "C:\Source\Project\Production\2.4.0.0"
PS H:\> $files = get-childitem $projectLocation -include *.*proj -recurse |
Select-String -pattern "Common\Main" -SimpleMatch |
Select-Object -Property Path
PS H:\> $files | Foreach-Object { CheckOutTfsFile( $_.Path) }
PS H:\> $match = "Common\\Main"
PS H:\> $replacement = "Common\Production\2.4.0.0"
PS H:\> $files | Foreach-Object
{ (Get-Content -Path $_.Path -encoding UTF8 )
-replace $match, $replacement
| Set-Content $_.Path -encoding UTF8 }
It worked out very well for me. All of the files were updated in a few seconds. I compared a few against their previous versions and it all looked good. Checked it into Team Foundation Version Control, started a manual CruiseControl build, and I was done.
There's definitely room for improvement in the name of reusability. I don't expect to have to do this too often, however, so I'm going to defer that for another day.
Did I mention that the project files were under TFS version control? I created the following helper function to check out the files. I didn't create a corresponding function to check in the files because I wanted to eyeball them before check-in.
function CheckOutTfsFile([string] $FilePath)
{
Write-Host("Attempting to check out " + $FilePath)
$tfsvc = Get-TFSVersionControl
$ws = $tfsvc.GetWorkspace((Get-Item $FilePath).DirectoryName)
$ws.PendEdit($FilePath)
}
So here's the actual code. I needed to alter part of the path to the 'Common' project in 30+ Visual Studio 2008 project files. Specifically, I needed to change every instance of 'Common\Main' to 'Common\Production\2.4.0.0' to support a source code branch.
PS H:\> $projectLocation = "C:\Source\Project\Production\2.4.0.0"
PS H:\> $files = get-childitem $projectLocation -include *.*proj -recurse |
Select-String -pattern "Common\Main" -SimpleMatch |
Select-Object -Property Path
PS H:\> $files | Foreach-Object { CheckOutTfsFile( $_.Path) }
PS H:\> $match = "Common\\Main"
PS H:\> $replacement = "Common\Production\2.4.0.0"
PS H:\> $files | Foreach-Object
{ (Get-Content -Path $_.Path -encoding UTF8 )
-replace $match, $replacement
| Set-Content $_.Path -encoding UTF8 }
It worked out very well for me. All of the files were updated in a few seconds. I compared a few against their previous versions and it all looked good. Checked it into Team Foundation Version Control, started a manual CruiseControl build, and I was done.
There's definitely room for improvement in the name of reusability. I don't expect to have to do this too often, however, so I'm going to defer that for another day.
Friday, April 18, 2008
TFS Pain
We recently migrated the source code of one of our products (which I'll call ACME) from Visual Source Safe to Team Foundation Version Control. This change necessitated a change to the ACME's project configuration in CruiseControl.NET. While not as painful as surgery, the procedure was extraordinarily frustrating.
You might wonder why we're using CC.NET if the TFS Build Server is available. It's all a matter of timing. ACME is a 2+ year migration of an existing application written in Oracle Forms. We're near the end of the project and CC.NET has performed admirably the entire time. It was disruptive enough to educate everyone on TFS in order to use WorkItem Tracking and source control. I just want to finish the migration at this point so TFS Build can wait a couple more months.
I started the process on 4/18/2008 by configuring the development CC.NET server to use our development TFS source control. Installing the CC.NET TFS plugin was easy enough. I then created a local account on the TFS machine that had the same name and password as the owner of the CC.NET service. I then granted read permissions to this account so that it could access the ACME source code. I was able to successfully build in a really short period of time. It was now time for the real thing.
Repeating the process that I'd used in the development environment, I installed the CC.NET TFS plugin. And the install consisted of copying the TFS plugin files from the development server to the production server. Upon starting the CC.NET service I received the following exception in the Event Log:
Event Type: Error
Event Source: CCService
Event Category: None
Event ID: 0
Date: 4/18/2008
Time: 4:04:03 PM
User: N/A
Computer: CORP-TWDEV
Description:
Service cannot be started. System.BadImageFormatException: The format of the file 'ccnet.vsts.plugin.dll' is invalid.
File name: "ccnet.vsts.plugin.dll"
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Exortech.NetReflector.NetReflectorTypeTable.Add(String path, String searchPattern)
at ThoughtWorks.CruiseControl.Core.Config.NetReflectorConfigurationReader..ctor()
at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.NewConfigurationService(String configFile)
at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.Create(Boolean remote, String configFile)
at ThoughtWorks.CruiseControl.Service.CCService.CreateAndStartCruiseServer()
at ThoughtWorks.CruiseControl.Service.CCService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\CI\CruiseControl.NET\server\ccnet.vsts.plugin.dll
LOG: Appbase = C:\CI\CruiseControl.NET\server\
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/CI/CruiseControl.NET/server/ccnet.vsts.plugin.dll.
Here was my first problem. My development environment was running a newer version of CC.NET based on the .NET 2.0 framework. Our production environment was running against the .NET 1.1 framework. The TFS plugin is a .NET 2.0 application. I would have to upgrade CC.NET on our production server before I could proceed. This was an unexpected development.
So I backed up all of my CC.NET configuration files and upgraded. The upgrade went smoothly and was fast. The service started this time. But my builds were failing with no explanation. I dove into the CC.NET log file.
Ah, here was the culprit!
2008-04-18 16:30:47,458 [5940:INFO] Force Build for project: ACME
2008-04-18 16:30:47,458 [5940:INFO] Project: 'ACME' is added to queue: 'ACME' in position 0.
2008-04-18 16:30:47,552 [ACME:INFO] Project: 'ACME' is first in queue: 'ACME' and shall start integration.
2008-04-18 16:30:47,645 [ACME:ERROR] INTERNAL ERROR: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
----------
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
The TFS version 9 assemblies, which were installed on the development box, couldn't be found by the CC.NET TFS plugin on production. Why not? We were using Visual Studio 2005 at the time so I'd continued to use the version 8 assemblies on the production server. Anyway, I now had to go back to the TFS plugin site on CodePlex and get the version that worked against the 8.0 binaries installed on my production build server. Could I have just copied the version 9 assemblies from dev to prod? Sure, but I was getting concerned about the number of changes I was suddenly making to the build server. (I've since upgraded to Version 9.)
So back to CodePlex I go, or tried. Some corporate firewall change had been made, and every time I tried to go to CodePlex I got this error message: "Internet Explorer cannot download View.aspx from www.codeplex.com." At least IE7 gave me an error message- Firefox just displayed a page of control characters. I used Remote Desktop to connect to some different machines and was finally able to access CodePlex using IE 6. Got the 1.3 version of the TFS plugin and was ready to build!
But not so fast...
2008-04-18 16:49:28,306 [ACME:INFO] Project: 'ACME' is first in queue: 'ACME' and shall start integration.
2008-04-18 16:49:28,306 [ACME:DEBUG] Checking Team Foundation Server for Modifications
2008-04-18 16:49:28,306 [ACME:DEBUG] From: 4/18/2008 9:28:47 AM - To: 4/18/2008 4:49:28 PM
2008-04-18 16:49:28,384 [ACME:ERROR] INTERNAL ERROR: TF30063: You are not authorized to access http://tfs:8080.
Nice. OK, it seems that though I had two identically named accounts on both the build and TFS server, the passwords were different. So I synchronized the passwords, which then broke my Oracle continuous integration solution. The Oracle CI project still lives in VSS because the Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider doesn't work correctly for us. This VSS instance is on yet another machine so I had to sync another password and then the Oracle project was back online.
And then this,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets (3340,9): errorMSB3482: SignTool reported an error 'Key not valid for use in specified state. '.
We're still using a temporary key to sign the ClickOnce manifest. Something somewhere changed and I had to supply a password. This required logging into the build server using the credentials of the local account used to run the CruiseControl.NET service. And to be able to do that I had to login to the machine and add the local account to the Remote Desktop Users group.
Ah, so finally I'm finished, right? No.
ThoughtWorks.CruiseControl.Core.CruiseControlException: Unable to load
transform: e:\dev\CruiseControl.NET\webdashboard\xsl\msbuild.xsl --->
System.Xml.Xsl.XslLoadException: XSLT compile error. An error occurred
at e:\dev\CruiseControl.NET\webdashboard\xsl\msbuild.xsl(0,0). --->
System.Xml.XmlException: For security reasons DTD is prohibited in
this XML document. To enable DTD processing set the ProhibitDtd
property on XmlReaderSettings to false and pass the settings into
XmlReader.
The previous version of CC.NET had been based on the .NET 1.1 framework, which allowed DTD's. The version of CC.NET that I had just upgraded to doesn't allow DTD's. because it's based on the 2.0 .NET framework. Some of the XSL files that ship with CC.NET use DTD's. Google to the rescue again.
You might wonder why we're using CC.NET if the TFS Build Server is available. It's all a matter of timing. ACME is a 2+ year migration of an existing application written in Oracle Forms. We're near the end of the project and CC.NET has performed admirably the entire time. It was disruptive enough to educate everyone on TFS in order to use WorkItem Tracking and source control. I just want to finish the migration at this point so TFS Build can wait a couple more months.
I started the process on 4/18/2008 by configuring the development CC.NET server to use our development TFS source control. Installing the CC.NET TFS plugin was easy enough. I then created a local account on the TFS machine that had the same name and password as the owner of the CC.NET service. I then granted read permissions to this account so that it could access the ACME source code. I was able to successfully build in a really short period of time. It was now time for the real thing.
Repeating the process that I'd used in the development environment, I installed the CC.NET TFS plugin. And the install consisted of copying the TFS plugin files from the development server to the production server. Upon starting the CC.NET service I received the following exception in the Event Log:
Event Type: Error
Event Source: CCService
Event Category: None
Event ID: 0
Date: 4/18/2008
Time: 4:04:03 PM
User: N/A
Computer: CORP-TWDEV
Description:
Service cannot be started. System.BadImageFormatException: The format of the file 'ccnet.vsts.plugin.dll' is invalid.
File name: "ccnet.vsts.plugin.dll"
at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Boolean isStringized, Evidence assemblySecurity, Boolean throwOnFileNotFound, Assembly locationHint, StackCrawlMark& stackMark)
at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Boolean stringized, Evidence assemblySecurity, StackCrawlMark& stackMark)
at System.Reflection.Assembly.LoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
at Exortech.NetReflector.NetReflectorTypeTable.Add(String path, String searchPattern)
at ThoughtWorks.CruiseControl.Core.Config.NetReflectorConfigurationReader..ctor()
at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.NewConfigurationService(String configFile)
at ThoughtWorks.CruiseControl.Core.CruiseServerFactory.Create(Boolean remote, String configFile)
at ThoughtWorks.CruiseControl.Service.CCService.CreateAndStartCruiseServer()
at ThoughtWorks.CruiseControl.Service.CCService.OnStart(String[] args)
at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)
=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\CI\CruiseControl.NET\server\ccnet.vsts.plugin.dll
LOG: Appbase = C:\CI\CruiseControl.NET\server\
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/CI/CruiseControl.NET/server/ccnet.vsts.plugin.dll.
Here was my first problem. My development environment was running a newer version of CC.NET based on the .NET 2.0 framework. Our production environment was running against the .NET 1.1 framework. The TFS plugin is a .NET 2.0 application. I would have to upgrade CC.NET on our production server before I could proceed. This was an unexpected development.
So I backed up all of my CC.NET configuration files and upgraded. The upgrade went smoothly and was fast. The service started this time. But my builds were failing with no explanation. I dove into the CC.NET log file.
Ah, here was the culprit!
2008-04-18 16:30:47,458 [5940:INFO] Force Build for project: ACME
2008-04-18 16:30:47,458 [5940:INFO] Project: 'ACME' is added to queue: 'ACME' in position 0.
2008-04-18 16:30:47,552 [ACME:INFO] Project: 'ACME' is first in queue: 'ACME' and shall start integration.
2008-04-18 16:30:47,645 [ACME:ERROR] INTERNAL ERROR: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
----------
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.TeamFoundation.VersionControl.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.MultiSourceControl.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
The TFS version 9 assemblies, which were installed on the development box, couldn't be found by the CC.NET TFS plugin on production. Why not? We were using Visual Studio 2005 at the time so I'd continued to use the version 8 assemblies on the production server. Anyway, I now had to go back to the TFS plugin site on CodePlex and get the version that worked against the 8.0 binaries installed on my production build server. Could I have just copied the version 9 assemblies from dev to prod? Sure, but I was getting concerned about the number of changes I was suddenly making to the build server. (I've since upgraded to Version 9.)
So back to CodePlex I go, or tried. Some corporate firewall change had been made, and every time I tried to go to CodePlex I got this error message: "Internet Explorer cannot download View.aspx from www.codeplex.com." At least IE7 gave me an error message- Firefox just displayed a page of control characters. I used Remote Desktop to connect to some different machines and was finally able to access CodePlex using IE 6. Got the 1.3 version of the TFS plugin and was ready to build!
But not so fast...
2008-04-18 16:49:28,306 [ACME:INFO] Project: 'ACME' is first in queue: 'ACME' and shall start integration.
2008-04-18 16:49:28,306 [ACME:DEBUG] Checking Team Foundation Server for Modifications
2008-04-18 16:49:28,306 [ACME:DEBUG] From: 4/18/2008 9:28:47 AM - To: 4/18/2008 4:49:28 PM
2008-04-18 16:49:28,384 [ACME:ERROR] INTERNAL ERROR: TF30063: You are not authorized to access http://tfs:8080.
Nice. OK, it seems that though I had two identically named accounts on both the build and TFS server, the passwords were different. So I synchronized the passwords, which then broke my Oracle continuous integration solution. The Oracle CI project still lives in VSS because the Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider doesn't work correctly for us. This VSS instance is on yet another machine so I had to sync another password and then the Oracle project was back online.
And then this,
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets (3340,9): errorMSB3482: SignTool reported an error 'Key not valid for use in specified state. '.
We're still using a temporary key to sign the ClickOnce manifest. Something somewhere changed and I had to supply a password. This required logging into the build server using the credentials of the local account used to run the CruiseControl.NET service. And to be able to do that I had to login to the machine and add the local account to the Remote Desktop Users group.
Ah, so finally I'm finished, right? No.
ThoughtWorks.CruiseControl.Core.CruiseControlException: Unable to load
transform: e:\dev\CruiseControl.NET\webdashboard\xsl\msbuild.xsl --->
System.Xml.Xsl.XslLoadException: XSLT compile error. An error occurred
at e:\dev\CruiseControl.NET\webdashboard\xsl\msbuild.xsl(0,0). --->
System.Xml.XmlException: For security reasons DTD is prohibited in
this XML document. To enable DTD processing set the ProhibitDtd
property on XmlReaderSettings to false and pass the settings into
XmlReader.
The previous version of CC.NET had been based on the .NET 1.1 framework, which allowed DTD's. The version of CC.NET that I had just upgraded to doesn't allow DTD's. because it's based on the 2.0 .NET framework. Some of the XSL files that ship with CC.NET use DTD's. Google to the rescue again.
Subscribe to:
Posts (Atom)
