If you're an MSDN subscriber, you might be wondering what parts you can get hold of without purchase the product. Expression Studio is made up of: Expression Web, Expression Blend, Expression Design and Expression Media. From a developer's perspective, it is really Expression Web and Expression Blend that are of greatest interest. You might be able to make the case for including Design in this list, but personally (since I was born without the graphics gene), I wouldn't
Microsoft has thankfully included the two pieces (Web and Blend) into the MSDN Premium subscription. Expression Web can already be downloaded. Expression Blend will be available in the very near future. See Soma's announcement (from earlier this month) here.
For weeks now, there has been a buzz about a big announcement at the Mix '07 conference. Well, in his keynote, Ray Ozzie made the following announcements:
Expression Studio is shipping today - See here for the details. One of the interesting elements of Expression Studio is that it includes the standard edition of Visual Studio 2005. As I mentioned in my last post, I haven't seen the developer experience for Silverlight. Hopefully with this will be at least similar to what developers already expect.
Silverlight Streaming - A companion service to Silverlight. The idea is to allow Silverlight applications to be posted to a set of Microsoft servers in the cloud. From this cloud, the applications can then be delivered to client browsers through your web site. First I've heard of this, so if I misunderstood this 'third part' of the Microsoft strategy, I'll correct it later.
Scott Guthrie announce that Silverlight includes a cross-platform .NET Framework. As of 20 minutes ago, there was a preview for this functionality that was available on the web. While it is a Beta version, it does have a "Go Live" license.
Silverlight can be downloaded from here. The SDK can be found here.
More to come
I'm hoping that someone reads this post and corrects me. But I'm not holding out much hope.
I don't normally use TableAdapters, but for a small application I decided that they seem like a reasonable choice. And so long as I was using them on my development platform, all was well and good. The problem arose when I delivered the application.
Like any good developer, I store the connection string to the data store in the configuration file. Which is what I did for this application. When I defined the TableAdapters, I pointed the connection string property to the same setting. Or so I thought. But what actually happened was that the connection string was actually stored in the DLL that contained the adapters. Hard-coded. As in not modifiable through the config files. And, naturally, this wasn't discovered until deployment.
So I started to look for ways to have the TableAdapter pull the connection string from the config files. I figured that this would be a fairly common scenario, so it should be address. Not so much
Apparently there is no way to automatically have TableAdapters use config settings. The "solution" is to use the fact that TableAdapters are partial classes to create a write-only ConnectionString property. It looks like the following:
public partial class FormTableAdapter
{
public string ConnectionString
{
set
{
System.Data.SqlClient.SqlConnection conn = new
System.Data.SqlClient.SqlConnection();
conn.ConnectionString = value;
this.Connection = conn;
}
}
}
}
Then, where the adapter is instantiated in your code, you set the ConnectionString property to the value from the config file.
To me, this is unacceptable. I was already a little skeptical of TableAdapters (I don't like the DataSet and the data access code in the same assembly), but this takes the cake. It almost seems like they were designed to not allow a reasonable deployment model. Maybe it will get better in the next version, but until then, I'm sticking with DataAdapters.
This coming Saturday (April 28th), I'm going to be doing my Extending the ObjectDataSource talk at the Calgary Code Camp. While this isn't the first time I've spoken in Calgary (I did an MSDN User Group Tour there a couple of years ago), it has certainly been a while. I'm looking forward to participating as well as connecting with some people I haven't seen in a while. If you are in the area, you should seriously think about attending. Code Camps are a lot of fun and the price (free) enhances the value even more. You can find out more about the sessions and register at http://www.calgarycodecamp.com
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. :)
Those of you who actually read my blog on a regular basis might have wondered what had happened to me. While I’ve never been a ‘post-a-day’ kind of writer, it’s rare to have two months go by without a post of any substance. Well, I do have a reason for my absence.
I have spent the past months working on three separate writing projects, specifically the training kits for the Web, Windows and Enterprise Pro exams that are part of the MCPD certification. The names are too long to include, but they are MCPD Self-Paced Training Kits for exams 70-547
(Web), 70-548 (Windows), and 70-549 (Enterprise). None of these books are available yet (Amazon has them being released on Feb 28th), but I put the final stamp of approval on my part a short time ago.
This isn’t the first book I’ve been involved in. The other one was called The ASP 3.0 Code Maintenance Handbook from Wrox. The Friday before it was release, Wrox went bankrupt, so you can imagine that it didn’t sell incredibly well. In one of life’s little ironies, all three of these unreleased books are already selling better than my first ever did. And I can’t imagine that I’m a bad enough writer to drive Microsoft press out of business.
Anyway, once the holiday season has passed, I fully expect to be increasing my blog post output. So look for topics of interest for people who are working with ASP.NET 2.0, as well as anything else that might catch my interest.