I ran across this issue today when working with a WCF service project. We had generated a settings file through the project properties and in turn added entries into the web.config transform files for the different deployment modes. The base config and the transform blocks for the <applicationSettings> element were what you would expect:
Web.config:
<applicationSettings>
<Namespace.Properties.Settings>
<setting name="test" serializeAs="String">
<value>test</value>
</setting>
<Namespace.Properties.Settings>
</applicationSettings>
Web.Release.config:
<applicationSettings>
<Namespace.Properties.Settings xdt:Transform="Replace">
<setting name="test" serializeAs="String">
<value>test transform</value>
</setting>
<Namespace.Properties.Settings>
</applicationSettings>
However, when a deployment package or publish was called and the transforms occured we were experiencing runtime errors when the values were evaluated by the code. After inspecting the transformed Web.config I noticed that the <applicationSettings>block now had additional linebreaks and whitespace added to the <value> element causing the string values to resolve as invalid in the code.
Transformed Web.Config:
<applicationSettings>
<Namespace.Properties.Settings xdt:Transform="Replace">
<setting name="test" serializeAs="String">
<value>
test transform
</value>
</setting>
<Namespace.Properties.Settings>
</applicationSettings>
Did some research and found the a discussion of the issue on Microsoft Connect. Seems as though there is a workaround involving an override addition to the Settings.cs file of the project that can be implemented while waiting for a HotFix. Or you could just call Trim() on every line where you use one of these values.
Good luck!
WORK IN PROGRESS - I WILL UPDATE WITH DETAILED STEPS SOON
IF YOU HAVE SPECIFIC QUESTIONS PLEASE COMMENT AND I WILL RESPOND ASAP
I have just completed the arduous process of integrating ClickOnce deployment (with
the ability to have multiple versions installed side-by-side EX: DEV,QA,UAT) into
my TFS 2010 build script. This took me about a week due to lack of materials
on the web. So for everyone else out there attempting this here is what I did to
make it work.
In order for this to work you must have the MSBUILD community tasks installed on
you build server. You can download these from here msbuildtasks.tigris.org
1) Create a "version.txt" file in your ClickOnce deployment virtual
directory to track the app version:
- The file "version.txt is one single line and it follows the "Major.Minor.Build.Revision"
standard (1.0.0.0)
- The following step uses the MSBUILD community tasks to read this file and
update the app version
2) Create custom target file to handle all manifest/bootstrapper generation as well
as the deployment web page template:
- Create the deployment web page template in a well known (easily accessible) place
in the project directory (mine is under a filder I created called "Publish")
- The template file I used can be downloaded from my SkyDrive
at ClickOnce Publish Page Template. Thanks to the DeveloperMine blog for supplying the initial template
and steps to modify.
- Create the custom target file in the root of your project directory (Mine is named
ClickOnceDeployment.targets)
- The contents of the ClickOnceDeployment.targets file are as
follows (download file from my SkyDrive at ClickOnceDeployment.targets):
- PLEASE READ THE INLINE XML COMMENTS FOR EXPLANATION OF EACH BLOCK
3) Modify your .csproj (C#) file to import the custom target file when it is
a teambuild:
- Open your .csproj file in notepad or any otehr text editor and add the following
line to the very bottom of the file.
<Import Condition="'$(BuildingInsideVisualStudio)' == 'false' AND $(BuildEnvironment)
!= '' AND '$(DeployClient)' == 'true'" Project="ClickOnceDeployment.targets"
/>
- The condition statement is reading some out of box and custom MSBUILD properties
that we will define and set when we create our build definition to actually perform
the build/deploy. In the end, this <Import> block will only run if the conditions
are met which will in turn only run the code in out ClickOnceDeployment.targets
file if these conditions are met.
4) Create build script template to provide the expected parameters to the custom
target file and call MSBUILD on your project:
(PLACEHOLDER)
These steps were compiled from many different sources and heavily modified to fit
my specific situation. I know that there are prob places where this can be improved
upon and if you happen to have feedback please leave it in the comments.
Hope that this shortens the amount of time it takes you to get ClickOnce working
with TFS 2010.
Microsoft has announced and released a Beta version of a new process template for Team Foundation Server 2010 that is based purely on Scrum Methodology and terms. You can download the new template from the link below
TFS Scrum v1.0 BetaFor a more in depth look review see the Visual Studio Magazine announcement HERE
The TFS 2010 Power Tools were released on the 23rd. Check out the link for download and info.
TFS 2010 PowerTools
At my current client we have about 15 or so users of Team Explorer Beta 2 that needed to be upgraded to the RC client (since I upgraded the server to RC). Out of those 15 there were 2 cases of users experiencing installs that would crash after reaching the Complete/Custom selection screen. One of the users was on a laptop running XP SP 3 and the other was on a desktop running XP SP 3. After many attempts (command line install w/ supressed UI, registry changes, etc.) at getting the setup to run correctly and install a working copy of Team Explorer 2010 RC failed I did some searching and found a few people running into the same problem.
The general idea for a fix was that the Language Bar needed to be disabled in order for the install to be successful. So I gave it a shot and it worked. Both users are now happily running complete installs of Team Explorer 2010 RC. My steps taken are defined below:
- Click Start, click Control Panel, and then double-click Regional and Language Options.
- On the Languages tab, under Text services and input languages, click Details.
- Under Preferences, click Language Bar.
- Deselect the Show the Language bar on the desktop check box.
- Extra step in my case: Remove handwriting recognition in the listbox on the parent window.
- If the language bar is still present on the taskbar right-click it and remove it.
Not sure what the language bar has to do with the setup.exe of Team Explorer or Visual Studio but this slight change turned a headache into a good day. If anyone has a reason of why this error is occuring please post it in the comments.
Hope this is helpful to those who find it.
I performed an in place upgrade of a TFS 2010 Beta 2 instance to and RC instance yesterday using this guide:
TFS Beta 2 to RC Upgrade Guide
The overall process was relatively smooth. There was only one hiccup at the very end of the "Upgrade from previous version" config wizard that almost had me in tears.
The last step was to upgrade all exisiting Project Collections. What it seemed to do was put each collection into a queue and then falg them as being serviced. While in this state nothing could be done to the collections and they were offline. The problem I had was that they never passed the first step of this process and remained in the offline/servicing status for about an hour. After searching for some sort of activity (logs, processes, etc..) I nearly cancelled the whole thing due to lack of information and the overall feeling that the process had hung up. Out of nowhere the config wizard closed, as if finished, and returned me to the TFS Admin Console.
I looked through the application tier and the project collections were still offline and still queued for servicing. So I made the decision to perform an almighty restart on the server and hope for the best. When the server finally botted back up I went back in the admin console to check the status again and what I found was what I had hoped for, the project collection upgrade process was back in full swing and completinhg without error.
Not sure if this was an isolated error or not, since it the RC was just released, but I hope that if others have this problem my journey will provide some help.
Seems as though the "destroywi" command has been moved from the Power Tools into the actual TFS administration executables. I case you were wondering here is the /? from the new destroy work item command in TFS 2010.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE>witadmin destroywi /?
Work Item Tracking Administration tool. (C) Copyright 2006 Microsoft Corporation. All rights reserved.
Destroys a work item or work items. Currently, work items can only be destroyed. Destroying a work item means the work item is physically deleted and cannot be restored. The system does not support logical (and thus recoverable) deletion of work items.
Usage: witadmin destroywi /collection:collectionurl /id:id [/noprompt]
/collection Specifies the Team Foundation project collection. Use a fully specified URL such as
http://servername:8080/tfs/Collection0.
/id Specifies the ID of the work item to destroy. Supports multiple IDs delimited by commas
such as 12,15,23 (with no whitespace).
/noprompt Turns off the confirmation message.
I was looking for this using the old "tfpt destroywi" command and kept getting errors saying the command didn't exist when I finally did some searching and came across the new home for the command. Could be pretty helpful if needed.
Looking to the future release of Expression Blend 4 I had some questions on how things will work with TFS. The main thing Iw as looking for was work item creation based on SketchFlow screens embedded within Expression Blend itself. Well I found out the other day that the extent of this integration has been expanded on from the previous release but it isn't as robust as I had hoped. The following is the main point of the conversation I had.
- You will be able to create TFS work items from SketchFlow feedback, but you will not be able to create general work items from within Blend – this had to be cut...
For those looking forward to heavier integration it looks like those items had to be cut but I imagine they will continue to be developed upon and will be released in the future.
Steps to make MS Project create a log file of exceptions occuring during the load/refresh/publish using the "TFSOfficeAdd-In.dll" component.
1) Navigaate to the directory that winproj.exe lives in. (Typically "C:\Program Files\Microsoft Office\[Version]\" where [Version] is the Office version I.E. Office12, Office14)
2) Create a new text file named winproj.exe.config
3) Add the following XML as the contents of the winproj.exe.config file:
<configuration>
<system.diagnostics>
<switches>
<add name="General" value="3" />
</switches>
<trace autoflush="false" indentsize="3" />
</system.diagnostics>
</configuration>
From now on, anytime an error occurs with your synch, a log file is created in the "%temp%" directory titled "tfs_msproject.log"
I was running into an odd problem today when trying to add some new custom columns to a Microsoft Project project plan. These fields were driven by the values in other columns, in other words they calculated columns that used custom formulas I created to poluate them with content. I had added new fields to my project plan and validated and tested the formulas. Next I updated my task.xml to contain the new fields in TFS and uploaded that, then changed the FieldMapping.xml to reflect the mapping.
I had only added two new fields (and have done this many times before) so I wasn't at all worried about failure. Sure enough when I hit refresh the first time I received "TF82039: Team Foundation was unable to modify the project plan". I knew I couldn't have done anything wrong so I was worried that the fact that these columns were calculated was the issue. After much searching and no results I decided to troubleshoot a little more. I removed the mapping to one of the columns in my FieldMapping.xml and tried to refresh again. Project/TFS magically completed the process with no errors. So I went back and added the other field back in and voila, worked like charm.
I'm still not sure what the deal was, or why it let me add the one at a time. SO, if you run into this problem, try adding the new mappings one at a time. It also might help to create a tfs_msproject.log file to get the stacktrace and exception that occurs in your case.
I'll post steps to ensure that that file gets created later.