September 17, 2009
Recently I was faced with a failure in a Team Build caused by MSTest that crashed when firing up the Unit Tests.
MSBUILD : warning MSB6006: "MSTest.exe" exited with code -2146233082
Digging a bit deeper and running the Unit Tests manually with MSTest on the build server via the command line showed me a dialog box with the following notification:
MSTest.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
Nothing more, nothing less! Hmm … Note that this behavior only surfaced after SP1 of Visual Studio 2008 and TFS 2008 was installed on the build server. Before, everything worked fine. On my local development pc (with SP1 of Visual Studio 2008) all Unit Tests run without any problems.
Let’s take a look at the eventviewer to get some extra information of what’s going wrong here …
Two interesting events were logged:
- .NET Runtime version 2.0.50727.3053 – Fatal Execution Engine Error (7A035E00) (80131506)
- Faulting application mstest.exe, version 9.0.30729.1, stamp 488f21a6, faulting module mscorwks.dll, version 2.0.50727.3053, stamp 4889dc18, debug? 0, fault address 0x001c5e00.
After searching for these errors on the web I came across some blog posts that mentioned the same Fatal Execution Engine Error but the scenario where this error occurred was totally different. It had something to do with Visual Studio disappearing unexpectedly but apparently there was a hotfix available on Microsoft Connect for this Fatal Execution Engine Error. So, with no other options at that moment I decided to go for the hotfix and see what happened.
The hotfix indeed did fix the problem, but I’m still puzzled what actually caused the problem. Strange was that certain Unit Test assemblies did run well on the build server while others even didn’t get started due to the above conditions …
[I did also log this error on the Testing forum of Visual Studio Team System]
September 7, 2009
Last week I spent way too much time on troubleshooting an issue with generating a ClickOnce package with a Team Build. Generating the package was actually not the problem, but running the application always resulted in …
Reference in the manifest does not match the identity of the downloaded assembly x
It was clear that something was wrong with the manifest, but I could not find what was keeping the application from launching. I checked and double checked the build script and the way the package was built but could not find an indication of the above error. Publishing the application from within Visual Studio 2008 seemed to work without any hitches and it was then that I noticed the following setting in the Application Tab of the Start Project in Visual Studio.
Visual Studio 2008 embeds by default a manifest inside an assembly. This means that the ClickOnce executable was using this default manifest instead of the manifest that was generated with Team Build. Switching to the other option to not generate a manifest with Visual Studio did solve the issue!
Hopefully I can save someone’s time with this blogpost!
September 3, 2009
Recently (in TFS2008) I was stuck with the fact that I could not split up the permission to create/modify builds and the permission to create/modify build agents. In certain enterprise environments it might be necessary to revoke the right from development teams to create/modify build agents. Build agents may be for instance controlled centrally by an operations team that manages all build servers. In TFS2008 both tasks belong to the “Administer a buid” permission.
The good news is that TFS2010 will offer a lot more fine-grained permission sets! You will now have the possibility to set permissions on the Team Project Collection, on the Team Project, on the Build Definition level and on the Version Control repository!
- Team Project Collection
- Administer shelved changes
- Administer test controllers
- Administer warehouse
- Administer workspaces
- Alter trace settings
- Create a workspace
- Create new projects
- Delete a team project
- Delete team project collection
- Edit collection-level information
- Make requests on behalf of others
- Manage build resources
- Manage process template
- Manage work-item link types
- Trigger events
- Use build resources
- View build resources
- View collection-level information
- View system synchronization information
- Team Project
- Administer test environments
- Create test runs
- Create team project
- Delete test runs
- Edit project-level information
- View project-level information
- View test runs
- Build Definition
- View Builds
- Edit build quality
- Retain indefinitely
- Delete builds
- Manage build qualities
- Destroy builds
- Update build information
- Queue builds
- Manage build queue
- Stop builds
- View build definition
- Edit build definition
- Delete build definition
- Override check-in validation by build
- Version Control
- Check Out
- Check In
- Revise other users’ changes
- Unlock other users’ changes
- Undo other users’ changes
- Administer labels
- Manage permissions
- Check-in other users’ changes
- Manage branch
Great! There are a few permission that are new and that I certainly want to look into a bit deeper … but now let’s go back to my problem in TFS2008 and how to fix it in TFS2010. Right clicking the Team Project Collection brings me to the permissions on the Project Collection level.
The permission to Manage build resources allows people to create and modify build controllers and agents.
Right clicking Builds brings you to the permissions on the build definition level.
The permission to Edit build definition allows people to create and modify new build defnitions.