Last blog post entry I mentioned the little gotcha with the vague Excel Export error
TF80012: The document cannot be opened because there is a problem with the installation of the Microsoft Visual Studio v10.0 Team Foundation Office integration components. Please see the Team Foundation Installation Guide for more information.
And the solution to this cryptic little guy was to enable the Team AddIn from Excel AddIn Manager – which would make for a far better error message next time.
2) Compilation of certain solutions with many forms fails with RESGEN error
MSB6002: The command-line for the "ResGen" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "ResGen" into multiple calls with fewer parameters per call.
We had 2 projects that would fail due to the large number of forms they possess and therefore a large number of resource files to deal with. Microsoft admits it was fixed in Beta 1 but they regressed in Beta 2 and allowed the error back in (hmmm, I suspect some missing unit tests 🙂
This post https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499196&wa=wsignin1.0 will help you as it did us as basically the fix involves a change to the Microsoft.Common.Targets file on your build machine. Now it does increase the build time slightly as this fix forces the compile to resolve 1 resource at a time rather than grouping a bunch on the command line as it had been doing but the overall impact wasn’t that noticeable and seems to be a very good workaround until RTM version in which Microsoft promises this has been corrected.
3) License Compiler Issue on 64-bit build machine
LC: ‘Could not load file or assembly ‘file:///C:BuildsFinancialsVersion 2.6.0SourcesVersion 2.6.0_DependenciesAtalasoft.DotImage.Annotate.dll’ or one of its dependencies. An attempt was made to load a program with an incorrect format.’
This one had us stumped for awhile – we found a few posts such as this one http://forums.ni.com/ni/board/message?board.id=232&message.id=3965 that even other component makers suggested looking at – in the end, we once again cracked open the Microsoft.Common.Targets file on our build machine and forced it to always use the 32-bit version of the License compiler (LC.exe) rather than the 64-bit version LC64.exe it wanted to use regardless if the project was setup to target the 32-bit (x86) platform. That seemed to do the trick – this workaround didn’t feel so great to us and left us feeling a little dirty but since most of our projects (due to 3rd-party components) are built in 32-bit mode anyway – we feel comfortable waiting for a response from Microsoft on this issue
These last 2 are of the user error variety – I hesitate to list them but why not – just in case you do something as dumb as I did, you may as well know about them as well
4) Compiler Errors – "Could not load file or assembly"
So while researching Issue #3 above, I started getting some new errors while tweaking the build scripts, and experience has taught me to look for the first error in the error log and not look at the ones below it since they are usually a result of the top ones cascading…..but look at the picture below
I was so concerned (especially after fighting through so many registration and license compiling issues – that were not Team related but involving other 3rd-party components) over the first error that I never bothered to look at the second error which would have been my big clue…..it wasn’t until I actually starting doing diffs on the build scripts that I found I had set the BuildConfiguration to be "Any CPU" with a space between them rather than "AnyCPU" as it should be. And before I could blame Team Explorer for not warning me that I had specified an invalid Configuration to build…..crap – there it was on the very next line – didn’t think I could feel much dumber until the next error.
5) Unable to refresh Source Code
So all is up and working, finally feeling good like the migration has been a success and yet one developer seems unable to refresh source code for their application……but everyone else has no problems – he tries everything, even reinstalls Team Explorer 2010, and even tries to reinstall Visual Studio 2008 which is what we develop with – and still same problem….Team tells him his source code is up to date (when we can prove it is not) and if he tries to view history on a branch he gets this message
Then he plays with Team Security and remembers that he had asked me to allow him Project Manager access to his project which I did – however, prior to that since all of the other project managers were not coders, I had removed access for Project Managers to manipulate code. By me adding this developer to the Project Manager group – I had removed his ability to work with code at all in this project – EVEN THOUGH he was still a member of the Contributors group for that project with full rights. So we learned that Team will use the properties of the most restricted group an individual belongs to. OK, so I made a mistake that cost a developer hours of frustration and productivity – that sucks and I take full responsibility and blame – again sorry Lyle.
But I think a warning from Team would not have been asking too much stating that access was not allowed with this Security Group rather than quietly doing nothing and pretending that you were doing something – right?
And thats our story…….moving source code & build scripts was easy, setting up new build agents is easy, and all of this would have been fairly simple with the exception of the 2 forementioned Team errors where it required a quick Bing (yes, Bing – not Google) search to find a workaround…..90% of the time was spent on non-Team system related issues such as tracking down licenses, registration tools for 3rd party components – which we do not have many of and yet can still be painful for the few we have…..we use components from other companies for some communication protocols and interfacing to scanners, etc – things none of us want to write software for but just another reminder how it is best to remove dependencies (and not add more) unless absolutely required for the functionality of the program.
But now its time to get back to my "regular" work and try out some of these Team 2010 enhancements
Things I know I like already are:
Graphical representation of Branching changesets
Build Notification tool to monitor build activities of any project
Excellent Excel integration
Team Web Access – can do all of my work-item maintenance, reporting from browser without even bringing up Team Explorer shell
Hierarchical Work Items for Project Management
The rest I’ll check out and may blog about later as I get more experience with it
Have a good Thanksgiving