I'm doing some work creating WebPart components in ASP.NET 2.0 and discovered a dependency that I wasn't initially expecting...the need for a database.
It appears that in order to even place a WebPart onto a form, you need to have a database. Or at least a persistent data store. A little bit of investigation found this information available in a number of places. The WebPart isn't actually the problem, so much as the WebPartManager. The manager is responsible for keeping track of the various WebPartZones and which WebPart is in which Zone. To persist this information across iterations of the page, the location information is stored in a database. So, even when the page is displayed the first time, a database connection needs to be available.
While you can create your own provider, the easiest mechanism is to use the aspnetdb, which is also used by the Membership and Role providers. To add the database to an existing SQL Server instance (either SQL Server 2000 or 2005), use the aspnet_regsql command, which is found in c:\Windows\Microsoft.NET\Framework\v2.0.50215. Once the database is available, a connection string (call it AspNetDbConnectionString to match the upcoming example) should be defined in the web.config file, along with a webParts element that includes a personalization tag, similar to the following:
<webParts>
<personalization defaultProvider="SqlPersonalizationProvider">
<providers>
<add name="SqlPersonalizationProvider"
type="System.Web.UI.WebControls.WebParts.SqlPersonalizationProvider"
connectionStringName="AspNetDbConnectionString"
applicationName="/" />
</providers>
<authorization>
<deny users="*" verbs="enterSharedScope" />
<allow users="*" verbs="modifyState" />
</authorization>
</personalization>
</webParts>
I was using the BoundField element in ASP.NET 2.0’s GridView control. More specifically, I was attempting to use the DataFormatString element in order to change the look of dates and dollar amounts as they get displayed. Much to my dismay, it didn’t look like the format string was being applied to the data.
After digging around a bit (and making sure that my memory of the format codes was accurate), it turns out that the problem is caused by a combination of factors. The first is that the default value for the HtmlEncode is true. The HtmlEncode property determines whether the value of the bound field is HTML encoded before being transmitted to the browser. The second factor is that, when the DataFormatString is applied to the value, any HTML encoding takes place prior to the formatting.
When, for example, a date is rendered, the date value is converted to string using the ToString() method. The string is then HtmlEncoded. Finally, the String.Format method is used to format the string using your format codes. However, your date format codes won’t work because the ‘date’ is no longer a DateTime variable. It’s a string. So instead of formatting the data, it is displayed using the ToString() layout. The same problem exists for other non-string types, including currency, floats, etc.
The solution is to set the HtmlEncode attribute to false on the BoundField element. Now the value is not converted to a string prior to the Sting.Format method call, the result being that the String.Format method uses the typed value (not the ToString version) and the format string in the manner that you (and I) expect.
The registration page has been available since the middle of December (at http://www.torontocodecamp.net), but my heads-down end of year mode kept me from mentioning it until now.
If you’re not familiar with the Code Camp concept, it is a free day-long conference on all things geeky. Geeky to developers, that is. Code Camps are run on a Saturday to give people who might not normally be able to attend a conference the opportunity. The Toronto Code Camp has its focus on Microsoft technologies (although not exclusively) and includes content on current and future technologies, both at the introductory and advanced level.
For those of you who don’t get enough technology during the course of a normal week, the Code Camp is a wonderful opportunity to get the latest and greatest in information from some wonderful speakers. Also, if you have wanted to speak to a group of enthusiastic users, the Code Camp provides a nice, safe, informal environment to get started.
So if you haven’t registered already, get to the Toronto Code Camp site and sign up now. You’ll get much more than your money’s worth. :)
.gif)
As an early Christmas present, Microsoft released a welcome service pack for Visual Studio 2005 last week. There's downloads available for each appropriate edition including the team foundation server. Check the download pages for releases notes as well.
There is still another service pack/update in the wings to provider greater facilities for integration with Windows Vista. It is supposed to be available in the first quarter of 2007, but you can download the beta of that service pack now.
For sometime now, I've done almost all of my development exclusively in virtual machines such as VPC and VMWare. This has been the only sane way to minimize disruption with the transition from Windows XP to Vista on my primary notebook.
As an aside, I heard a rumour that the VMWare Workstation 6.0 beta now supports the option to run your IDE on your host OS, and then to deploy, run & debug inside a virtual machine. That is certainly going to open some interesting scenarios. I can see that being very helpful for automated unit testing on via a build server, testing out on multiple configurations, environments, operating systems, etc.
<rant>
At least not yet. There's lots of disgruntledness in the community about Microsoft own lack of preparedness.
If you bought a Zune and run vista, you'll have to resort to some hacking to get your new toy to sync up.
Want to run Visual Studio inside of Vista? Be prepared for a bumpy road.
You're a Microsoft Certified or Gold Partner and you're excited because Vista is now available for download so in an eager rush to be “ready“ you decide to deploy vista using your internal use licenses that you get as part of your partnership benefits. Sorry - there is no Volume License key available to partners yet.
</rant>
To be fair, Micrsoft has several “release” dates for Vista and depending on who you are - you pick whatever one suits you as your “deadline” for readiness. Here's a run down which might give you some idea of setting your expectations of when to get stuff you need.
RTM/Release to Manufacturing. This is the date the bits get signed sealed and delivered. This actually happends about 30 days prior to when you think it happens when the would be final code goes into a cooling period of “let's run it internally and see if we can live without wanting to make a last minute change” otherwise known as escrow. This is a deadline for many internal product teams at microsoft.
Release to MSDN for Download. In the case of Vista, this took about a week. I'm not sure why this takes so long - especially if MSDN could have had the preliminary bits in waiting (i.e. escrow build) a month earlier. Perhaps there is some bureaucracy in play here, but I'm not sure. There are product keys to get ready and the inevitable crunch on the servers when people start downloading. I don't think I've seen a major release of Visual Studio, Office, or Windows that hasn't crippled MSDN. And then there are product keys to get ready, etc.
Launch Day(s): This is mostly just marketing hoopla but there is certainly lots of effort here. This has very little to do with the software actually being complete. We saw this last November with the simultaneous launch of Visual Studio, SQL Server, and BizTalk. BizTalk wasn't ready for release until months after launch
November 30th: For Vista there is some magic date that was announcd. This might be a launch date only or may have some technical deliverables. This was the date that MS announced as the official release of Vista to Partners and Businesses. Perhaps this is the date that the Microsoft Partner Program folks used as their deadline for readying their systems for getting volume license keys. But considering that Partners are the ones that are going to be in most need of being “ready” (after developers) you'd think that the MPP folks would be “ready“. What most annoys me about this is the emails they send out to partners asking us if we're “ready“. How can we be ready if you're not ready.
January 30th: This is the official Consumer release date. You should expect to find Vista on store shelves and preloaded on computers this day. For many stakeholders, this is the deadline of all deadlines. I've heard that the Zune team is using this date as a deadline to get their Vista version to market. I've also heard that many computer makers are using this date as their deadline to get drivers readied.
With Visual Studio Tools for Office (VSTO), Microsoft has add some impressive development capability to build solutions on top of Excel, Word and even Outlook now. You may have even heard that notion that Office can be considered part of the Application Platform, which includes things like Smart Client, ASP.NET Web, Compact Framework, BizTalk, etc. etc. However, one of the questions I've had about this was related to versioning. If I build a VSTO solution on Office 2003, will it work with Office 2007 now that it has been released and your customers may start using it. What about new development on Office 2007 - will those work on 2003?
Well today I got a pretty definitive answer from Tim Heuer at Mircrosoft that I'll share.With Visual Studio Tools for Office (second edition) you can create office 2007 add-ins as well as Office 2003 add-ins. What about documents? VSTO second edition doesn't allow you to target directly Office 2007 for document level programming. However an document targeted for 2003 would work in 2007. Not bad.
So we have a few service packs to talk about....
Firstly, Visual Studio 2005, SP1 is now in beta testing. This is a fairly big service pack, lots of bug fixes, and the odd new feature. The list is not complete of things fixed yet but Microsoft promises to update that list when they ship. You can read the announcement here and if you like, register for the beta on the Microsoft Connect Site. In that announcement, Soma also goes on to talk about Vista support and what that means for Visual Studio 2002, 2003, and 2005. Keep in mind, this has little to do with your applications running on Vista - but is about running the development environment on Vista.
Secondly, Brian Harry anounced the beta availability for Team Foundation Server SP1. You can register for the download on the Microsoft Connect Site. I'm most thankful for full-fledged extranet support. As you may know, there are some security hiccups when not using a VPN and trying t pass through a variety of firewalls/proxy servers. This one should have been in the 1.0 release in my opinion, but better late than never.
I do a fair amount of Work Item Type customization for customers so I'm pretty excited about the ability to create custom controls on your work item forms.
Other notable improvements: Better performance and scale, Excel/Project 2007 Support, Support for the new Web Application Projects.
I have it on good authority that you don't have to worry about what version of the client you have for compatibility with the server. So feel free to mix and match, you know, like Garanimals.
You'll find increased scalability and better performance with Work Item Tracking, Version Control, and the Data Warehouse.
If you're developing custom MSBuild Tasks, and you're interested in testing them (and you should) using NUnit or VSTS there are a few considerations.
The first is the strategy you want to adopt for testing the custom task. In the spirit of “Unit” testing, you may choose to test only your code in the tightest scope possible. In this scenario, you may choose to new up your custom task, set some properties on it, and fire the Execute method.
Be forewarned however, that when you do this, you don't have the full Build engine around running around your task. If you use the built in task logging mechanism, i.e.
Log.LogMessage("QueueName {0}, Message {1}", this.queueName, this.message);
You'll get an exception thrown....
Error message:
Test method ExecuteTest threw exception:
System.InvalidOperationException: Task attempted to log before it was initialized.
Stack trace:
at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args)
at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowInvalidOperation(Boolean condition, String resourceName, Object arg0)
at Microsoft.Build.Utilities.TaskLoggingHelper.LogMessage(MessageImportance importance, String message, Object[] messageArgs)
at Microsoft.Build.Utilities.TaskLoggingHelper.LogMessage(String message, Object[] messageArgs)
...
If you still want to test your custom task like this, you can test for the presencen of the build engine and not use it's built in logging features....i.e.
if (this.BuildEngine!=null)
Log.LogMessage("QueueName {0}, Message {1}", this.queueName, this.message);
Of course, if you choose to fire off your custom build task within the scope of the build engine by executing a test build script harness (and that's a good idea too) you won't run into this problem, i.e.
Process buildProcess = new Process();
buildProcess.StartInfo.FileName = "C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\MSBuild";
buildProcess.StartInfo.Arguments = "testscript.msbuild /target:testTarget”;
buildProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
buildProcess.StartInfo.CreateNoWindow = true;
buildProcess.Start();
buildProcess.WaitForExit();
buildProcess.Close();
//TODO: Assert that the script did what it was supposed to do.
My preference is to do both types of tests. The first style is helpful in the case of my actual custom task being faulty. If the first style fails, I'm very certain that the error is within the guts of that task. The second style is helpful in more of an integration test way. If the second style fails (and not the first) it means there is a problem in the way I'm calling my custom task within a build script.
I'll be speaking at the Chicago .NET Users Group in Downers Grove on March 15th
Stay tuned for details....
http://www.cnug.org/Default.aspx?tabid=31
I just got through a grueling session of installing the release candidate for Team Foundation Server. And by grueling, I mean about 16 hours worth. And given all of the glowing reports, I was surprised that this install turned about to be more challenging that the Beta 3 Refresh.
My problem centered around one particular point in the process. After having installed IIS, SQL Server, and Sharepoint Services on a fresh version of Windows 2003 (and the .NET 2.0 Hotfix), the installation of TFS performs a health check. My results coming out of the health check was that the running SQL Server instance was using an unsupported collation. Now while I have installed SQL Server many times, I’ve never given much thought to the collation. So I started looking at the problem. Since I had made no changes during SQL Server installation (with respect to collation), I uninstalled SQL Server and reinstalled it specifically choosing the Latin1_General option. Also, because the instructions in the installation help file said that TFS didn’t support case sensitive, binary or binary 2 collations, I left all of the check boxes on that form blank. To no avail. The SQL Server collation was not supportable by TFS
Just to be clear, after all of the dust had settled, my SQL Server’s collation was Latin1_General_CI_AI and TFS just didn’t like that.
So I go digging into the installation log file and come across the SQL statement which gets executed as part of the collation health check:
SELECT * FROM (SELECT CONVERT(char(100), SERVERPROPERTY('collation')) AS Collation) as c WHERE (Collation LIKE '%[_]CS%') OR (Collation LIKE '%[_]AI%') OR (Collation LIKE '%[_]BIN%') OR (Collation LIKE '%[_]BIN2%')
The thing that stood out for me was the inclusion of the Collation Like ‘%[_]AI%’ clause. Unless I’m reading this wrong, it means that TFS doesn’t like Accent Insensitive collations. And I don’t see this small tidbit documented anyplace.
The sole bright spot is that after I reinstalled SQL Server with the ‘Accent – sensitive’ check box on the Collation Settings portion of the installation checked, all went well. I now have a running version of TFS that is capable of working over HTTP. Let the games begin.