I'm trying to create a custom work item if a build fails, but am getting this strange error message;
(Windows Vista Business, Microsoft Visual Studio 2010 Version 10.0.30319.1 RTMRel, Microsoft .NET Framework Version 4.0.30319 RTMRel)
My xml snippet is;
<UsingTaskTaskName="Microsoft.TeamFoundation.Build.Tasks.CreateNewWorkItem"AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll"/><TargetName="CreateWorkItem"><CreatePropertyValue="$(WorkItemTitle) overriden by me!!"><OutputTaskParameter="Value"PropertyName="WorkItemTitle"/></CreateProperty><CreatePropertyValue="$(ErrorWarningLogText) <a href='file:///$(DropLocation)\$(BuildNumber)\ErrorsWarningsLog.txt' > $(DropLocation)\$(BuildNumber)\ErrorsWarningsLog.txt </a >. "><OutputTaskParameter="Value"PropertyName="ErrorWarningLogText"Condition="Exists('$(DropLocation)\$(BuildNumber)\ErrorsWarningsLog.txt')"/></CreateProperty><MessageText="WorkItemTitle = $(WorkItemTitle)"/><MessageText="ErrorWarningLogText = $(ErrorWarningLogText)"/><CreateNewWorkItemBuildId="$(BuildNumber)"Description="$(WorkItemDescription)"TeamProject="$(TeamProject)"TeamFoundationServerUrl="$(TeamFoundationServerUrl)"Title="$(WorkItemTitle)"WorkItemFieldValues="$(WorkItemFieldValues)"WorkItemType="$(WorkItemType)"ContinueOnError="true"/></Target>
What is wrong? why can't it find the dll in question?
15 Answers Found
Are you using Teambuild 2008 or 2010?
If you are using 2010, you considerate to create the WI using the workflow instead of msbuild?
I am using Teambuild 2010. How do I do this using work flow?
In my xml the custom work item is triggered in an OnError event. I'm not familiar with the solution you suggest. It would be good if you could include some links etc for this.
The link is great and I had seen it before. You see I'm not using a .proj file, instead I'm using .xml file, the reasion is that I'm executing remote commands on a Linux box and a .proj cannot be used in quite the same way. (I do know about power tools).
The link above is meant for a .proj file.
The problem here is a) DevEnvDir has a blank value, therefore b) TeamBuildRefPath has a blank value and c) Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll does not exist.
I can fix a and b by using something similar to;
<DevEnvDir Condition="'$(DevEnvDir)'==''">"$(ProgramFiles)\Microsoft Visual Studio 10.0\Common7\IDE"</DevEnvDir>
but that's not desirable and in any case does not fix the problem of missing assembly. I have re-installed on two different machines (both with Vista) and the same problem persists.
The example provided in all MSDN/MS Blogs etc. is the same as what I have used (see original post) and yet this problem is not solved.
Keedo, as I said Team build 2010 uses a workflow to define the operataions in build process, one of those operation is to create a WI in case of failure.
The link Jakob sent show how to customize the workitem creation. You can change the witype, the title, or any other field.
The fact that you are using a linux have no relevance, because the work run in the build agent.
For more information in customizing the build process in tem build 2010 please reffear to this link: http://msdn.microsoft.com/en-us/library/dd647551.aspx
Alex, thanks. I understand all that, this doesn't answer the question of the missing assembly!
This is the top part of my make.xml file;
<?xmlversion="1.0"encoding="utf-8"?><ProjectDefaultTargets="SetEnv"xmlns="http://schemas.microsoft.com/developer/msbuild/2003"ToolsVersion="3.5"><ImportProject="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets"/><PropertyGroup><CleanCmd>clean:clean</CleanCmd><CompileCmd>compile</CompileCmd><PackageCmd>package</PackageCmd><InstallCmd>install</InstallCmd><ResultDir>C:\Builds</ResultDir></PropertyGroup><PropertyGroup><!--Enclose in "" since $(M2_HOME) path could include spaces--><Maven>"$(M2_HOME)\bin\mvn"</Maven><!--DevEnvDir Condition="'$(DevEnvDir)'==''">$(ProgramFiles)\Microsoft Visual Studio 10.0\Common7</DevEnvDir--><!--TeamBuildRefPath Condition="'$(TeamBuildRefPath)'==''">$(DevEnvDir)\IDE</TeamBuildRefPath--></PropertyGroup><!-- <<< >>> --><PropertyGroup><SkipWorkItemCreation>false</SkipWorkItemCreation><WorkItemType>Bug</WorkItemType><WorkItemFieldValues>System.Reason=Build Failure;System.Description=I did this</WorkItemFieldValues><WorkItemTitle>(I broke it)Build failure in build:</WorkItemTitle><DescriptionText>This work item was created by Team build on a build failure (when I broke it).</DescriptionText><BuildlogText>The build log file is at: somewhere</BuildlogText><ErrorWarningLogText>The errors/warnings log file is at: somewhere else</ErrorWarningLogText><UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems></PropertyGroup><!-- <<< >>> -->
This follows what's been described in the link priovided by Jakob and to which you refer. But it simply doesn't work!!
As for the link you provided, I've gone through this before [http://social.msdn.microsoft.com/Forums/en/tfsbuild/thread/5a52ac23-337b-4c77-913b-5034d202a190]. I'm not sure why the insistence that I should be using an xaml as opposed to xml, but in either
case things don't seem to work.
This is a standard installation out of the box on two separate machine
that don't work. It is even more frustrating when there are no information available and no-one from microsoft seems to be available (or able) to answer these questions.
I understand that you are confused. I will try to explain better.
In TFS2008 the only way to perform any task was by using msbuild. Every operations such as Getlatest, label, create WI, copy files, etc....
The xml that you are pasting are msbuild tags.
In Team build 2010, MS changed the way that you define a build. For now on all the operations are defined using a workflow (xaml), only the compilation still using the msbuild (for obvius reasons)
Using a workflow is much more powerfull, you can define try catch structures, you can use any framework namespace, you can easily understand the structure of the build, you can easily perform loops (anyone who tried do perform a simple loop in msbuild
can say that only this would be a good reason to abandon msbuild do control workflow)
Bottom line: Although you still capable to create a workitem using msbuild xml, i strongly recomend that you do this using the xaml workflow. Any other recommendation that you find in the internet might refeear to the tfs2008!
Thanks for taking the time to explain. I have read and researched a lot into xaml, but as a company we have made a decision to go with the xml solution. Without going into too much detail, it is not easy to change once a process has been established and
I wonder, did you get a chance to look at the last link I pasted? (here it is just in case), Cathy Kong's answer (who apparently is a MSFT Moderator)
was to reinstall with the invitation to let her know any follow up issues. Well I did that but she didn't even have the courtesy of replying. Looking at a lot of her so-called replies, they all say that the software should be reinstalled and that they should
get back to her with any further queries that then she ignores.
Then again this seems to be the general attitude in MSFT, as soon as a question becomes difficult or complicated, it is ignored. A lot of these threads seem to end with someone from MSFT saying re-install and then not providing any real reasons or solutions.
Now there are two very real and separate issues here,
a) The original post: referring to opening a copy of DefaultTemplate.xaml - this was an out-of-the-box installation (on separate machines) and both installations were giving the same error.
b) No one had a reply/reason/solution for this. So fine I tried the xml route, even copy-pasted some source out of MSDN (see here) but the error mentioned here persists.
You see, the issue here isn't how I create a work item, the issue is why am I getting these errors? I don't even get as far as creating a work item, anything I override is ignored (see both of my xml snippets here).
Why would a default xaml template supplied with the software not work?
Why the system cannot find an assembly that is so obviously part of tfs? If I need to install additional software, why does no-one seem to know what it is?
I'm sorry, but in my vision, this is a community forum, with a strong presence of MS guys, they help a lot. I learn a lot here, and try to help other users.
If you need a official position from microsoft, i think thatt you should open a process in support.microsoft.com, accord with your support contract.
Thanks for your reply. I'm really not that bothered about official positions or whatever, I'm just trying to get an issue resolved. That is the reason I've come to this forum and also the reason why I appreciate the time and effort people like you put into
All that said and done, it is still not clear to me why the default xaml template comes up with over 50 errors?
I am so sorry I didn't follow up the issue in your original thread.
I understand that your feeling, I am sorry I didn't supply a effective method. I will
pay more attention to the threads I replied, continue to strengthen my technology knowledge and hope can help you.
About this issue, I recommend to submit it on http://connect.microsoft.com/visualstudio, and our engineers will take it into consideration and you will receive a quicker response.
Thank you for your response.
I have done as you suggested and have submitted this issue on the connect website.
In time when I have a solution, I will update this thread for the benefit of others.
Thank you for your feedback!
I think this will be helpful to improve TFS products.
This issue is now solved.
For those who may be interested;
1) All my xml snippets posted here, I have now found out, refer to VS 2008 only! VS 2010 ignores them, hence the reason why I couldn't override default behaviour. See below for the solution;
2) Also the issue with DefaultTemplate.xaml causing 50 errors (and this is the silliest bit) is because just having Visual Studio 2010 on its own is not enough! You also have to install Visual Studio 2010 Professional (or higher) to get the assemblies that
DefaultTemplate.xaml refers too! In other words with TFS you cannot modify a standard build unless you purchase another license!
Both issues above will be resolved and you will be able to create your custmised work item and/or facny build scripts (llike ours) AFTER installing the Pro or higher version.
I’m glad to hear that you got it working. Thank you for sharing your experience here.
It will be very beneficial for other community members having the similar questions.