More TFS fun and games:
Team Foundation Server 2010 will happily install and configure Reporting Server for you to power all your reporting needs, but I've come up against the following issue when attempting to modify the existing reports, or create new ones:
When you click on "Report Builder" from the Reporting Services web interface, it opens up the click once application "Report Builder 1.0".
This application cannot open the reports that come with TFS process templates, and that are installed on Reporting Services - the error it reports is:
Cannot open this item
This report cannot be opened in Report Builder.
And if you check the details you see:
System.IO.StreamReader: The Report element was not found.
Which is odd, seeing as if I open the .rdl file in a text editor, I can clearly see the root Report element in there.
If you get the latest (at the time of writing 3.0) version of Report Builder, it will not connect to Reporting Services - it keeps claiming that either the services aren't configured, or I don't have permissions.
However, if you install version 2 of Report Builder, almost all your woes go away, and you can open and edit reports to your hearts content.
The only outstanding woe I had was when I opened a report from the server, edited it, and saved it and then my report appeared to break, claiming that the TfsOlapReportDS was invalid. To resolve that, I had to switch to the Properties tab of the report in the browser, select DataSources and re-map the report to the correct shared data source - once I'd done that, all future saves worked fine.
Filed under: Reporting Server, TFS
We're in the process of moving to Team Foundation Server 2010, and as part of the process, we're updating the process template we're using, creating branded versions of the default documents, etc. Also, with new projects kicking off we're able to really sort out which process template we're using.
However, while we're ironing these changes out, we obviously need to actually do some work - so to that end we'd tweaked a template, created our project using that, and in the background we can work on the template for other projects.
This has left us with two things:
-
A number of projects in our test Project Collection with portals in the wrong place in SharePoint.
-
A number of projects using out of date portals.
At the moment, we've not made any changes to the contents in SharePoint (beyond access rights), we're mostly just using the dashboards and reports, so the cost of recreating these templates isn't that high however I was having a lot of difficulty working out how to move existing portals, or how to rebuild a portal after creating the project - the New Team Project wizard includes the option "Do not configure a SharePoint site at this time", with no real guidance on how to create one later.
As this is currently looking at WSS, and these aren't publishing sites, I can't move them easily in SharePoint. We tried exporting them, and importing them into the new location, but that also didn't work - errors about a template missing from the _forms folder (I guess the default template for the excel reports document library).
I tried creating a new site in SharePoint using the TFS templates supplied, but that didn't pick up my changes to the template, nor set up/create the shared documents, or the project dashboard. I also tried creating a dummy project with a portal in the right place, disconnecting the portal in TFS, then pointing the right project at the portal and finally deleting the dummy project, which worked, but was going to be a lot of work for all the other projects.
Finally, I took a look at the actions included in the tfpt command line tool from the Team Foundation Server Power Tools and noticed:
addprojectportal Add or move portal for an existing team project
Pass this the path to TFS, the project and process template you want to move, and optionally the details for the SharePoint instance you want to use and away it goes, creating a new Project Portal for you with all the modifications you've made.
I would point out the following issue I've had with this tool, but it may be due to my usage of it: when I pointed this at a project that already had a portal, I expected the tool to move the portal for me, however (probably because the project was built using a different Process Template) I now have two portals for this project, the old one, and the new one, not a big deal, I can easily delete the old portal - TFS seems to be happily pointing at the new one.
Running it without the /verbose option seemed to fail - and the logs weren't very helpful. Running the same command with /verbose resulted in a successful run. I may have just been unlucky.
Morals of this post:
-
Always check the power tools first.
-
MS have a habit of not finishing things, and releasing the bits you actually need as power tools.
-
Mario Rodriguez rocks.
Filed under: SharePoint, TFS
Something I meant to include in yesterday's post was around the steps I'd taken to get TypeKit working with the new GoogleApi WebFont Loader hosted version.
As I'm not using Google AJAX api decided to just call the file directly, but I couldn't seem to get it to work using the docs on GoogleApi using the WebFontConfig object, however following the directions on the Git hub seemed to work better:
Call the webfont.js file:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
Then call load on the WebFont object:
WebFont.load({
typekit: { id: 'gjb1flq' }
});
Passing in your TypeKit Id, (not the Kit Id as is implied in the docs).
To reduce the "Flicker of Unstyled Text" I then added the following to my CSS:
.wf-loading h1 { visibility: hidden; }
.wf-loading h2 { visibility: hidden; }
.wf-loading h3 { visibility: hidden; }
.wf-loading #logo p { visibility: hidden; }
.wf-loading code { visibility: hidden; }
.wf-loading pre { visibility: hidden; }
.wf-active { visibility: visible; }
Basically, as the web fonts are loading, the WebFont.js applies the .wf-loading style to html element, then once they are all in, applies the .wf-active style.
Rather than following the guidance on the git hub page (which suggests having the base state of the h1 hidden, and only showing it when the fonts are active) I've gone down this route, so if the script fails to load, or is turned off, the titles, code, etc will still show, albeit in their default fonts.
If I really wanted to I guess I could implement font based activation as well, using the .wf-adelle1adelle2-n7-active event.
Filed under: AJAX, Site Updates
Bit of a Link List this one, but it's got a few nuggets in there too.
Thanks to my excellent web hosts LiquidSix Hosting who upgraded our servers within about a week of ASP.NET 4.0 coming out, I've been able to focus on pulling this site over to the latest platform.
There were various reasons for wanting to do this, from cleaner web.config files, the new <%: %> syntax for HTML encoding output, and indeed answering some of my issues with Entity Framework, but obviously the key reason is it's new and shiney 
The key issue I had with it was that I forgot to update one small part of my web.config:
<system.web>
<httpRuntime requestValidationMode="2.0"/>
</system.web>
As I'd forgotten to set this, I was unable to use any markup when editing my blogs. Thankfully the error message tells you exactly what to set, so the fix was easy.
Other tweaks that also went live this week:
-
TypeKit have recently opensourced their code, and added an events system, which means that in FireFox the Flicker of Unstyled Text should be somewhat less intrusive.
-
The launch of DoodleStatic to host my static files (JS, CSS, images) a small, cookieless domain to speed up download of the site infrastructure.
-
Changing my calls to jQuery and Typkit's core libraries to ajax.GoogleApis.com, so your browser should be able to find them in its cache where other sites have used them.
-
Thanks to Damien Gaurd for spending the time to point out how to use the System.ServiceModel.Syndication namespaces in the context of an ASP.NET MVC site, something I'd been meaning to do for some time.
And a few other minor tweaks to keep things tidy.
Filed under: ASP.NET, ASP.NET MVC, Site Updates
This is one of those "20/20 hindsight is a wonderful thing" posts.
The basic issue is that Visio and Project aren't really part of Office, and should probably be uninstalled before you upgrade the main Office Suite - don't rely on their installers to properly clean them out.
I didn't do this, and had the following symptoms floating around:
Visio 2007 and Project 2007 were both still listed in my All Programs menu, with a tool tip "Installs on first use".
I imagine that at somepoint after upgrading Visio 2007 to 2010, I typed Visio<enter> into my start menu, and Visio 2007 reinstalled itself. I then opened Visio 2010, and that reconfigured itself through an installer. I uninstalled Visio 2007 again from the "Programs and Features" control panel, deleted the links, and the files in C:\Windows\Installers\ that they were pointing at.
I thought I was happy - turns out I was wrong. I was working in SharePoint, and getting these odd javascript library not registered errors:
Message: Library not registered.
Line: 1935
Char: 4
Code: 0
URI: http://server/_layouts/1033/init.js?rev=ck%2BHdHQ8ABQHif7kr%2Bj7iQ%3D%3D
Running the Repair tool (Programs and Features, Office 2010, Change and select "Repair") and restarting my machine seems to have fixed the issue nicely.
I hope this helps somebody else, and saves them the hour or so of confusion it's caused me.
Filed under: Fixes