I’ve posted a couple of times earlier on .NET 3.5 in Windows 2000. The .NET framework 3.5 sits on .NET 2.0 SP2, which is only available to install on Windows XP and onwards. However, from experimentation, this does not mean that the same tricks don’t work. As long as you have .NET 2.0 SP1 installed, you can get away with copying most of the DLLs in with no trouble. It also seems to work with some of the newer ones.
Posts Tagged ‘.NET’
.NET 3.5 SP1 in Windows 2000
Monday, March 23rd, 2009
Assembly Build and Revision Numbers
Monday, March 23rd, 2009I hadn’t actually realised until last week that assembly build numbers are not automatically incremented on each build. I remember at some point in the past going looking for where Visual Studio was storing them, and being very confused as to how it managed to increment the build number without checking out any files in source control.
Last week I discovered that build numbers are actually based on the date – it is the number of days since a date specified in the registry (I think 1st Jan 2000 by default). For example, today’s build number with the default date is 3369. Since this behaviour can be a little annoying if you release multiple builds per day and your users refer to the build number, people have come up with various different solutions. I’ve found this one on CodeProject, but I haven’t actually tried it.
Revision numbers, on the other hand are related to the time of day. I’ve heard various different reports that they are the number of seconds since midnight, or half that, or a random number. Experimentally, they do seem to be related to the time, but I haven’t played around for long enough to work out the exact relationship. I’m also not sure what time zone is used to work this out – it may be the computer clock or it might be UTC or something else. Anyone who has bothered to actually do this, please feel free to post and let us know!
XAML, Microsoft Silverlight 2.0 and WPF
Sunday, March 22nd, 2009Whenever new technology comes about, there is an automatic reluctance to spend time looking into it. I think this is probably quite a sensible thing, since you can’t possibly keep up with everything going on at once. When Silverlight came out, I had a brief look at it and thought “oh, it looks like Microsoft are trying to compete with Flash.” I thought it wasn’t really worth worrying about at the time, as Adobe have pretty much got the market cornered as far as browser animation plugins go, and I didn’t think people would really want to bother installing another one.
More recently, I’ve had a bit more of a look at Silverlight, and I’m wondering whether to invest some time learning it. It does seem to be getting a bit more popular. One of the things that I’ve heard (I don’t know whether this is true), is that Silverlight will work off the same XAML documents as WPF, which means that you can create a single XAML file and use it as an interface for both web and Windows.
Granted, I don’t actually use WPF yet either – from what I’ve heard of that, it still needs some work before it is a full replacement for Windows Forms, and I have heard that it can cause speed issues. On the other hand, the idea of being able to create a single user interface which can be used for both web and windows is very appealing.
Let me step back for a minute and explain. XAML (Extensible Application Markup Language) is Microsoft’s XML based language which is used for defining user interface. I think they invented it for WPF (Windows Presentation Foundation), which is supposed to eventually replace Windows Forms. The idea is that you can define a user interface in an XML document (much as you do in HTML), and then it gets rendered.
You may ask “why not just use HTML?” The answer is that while HTML has plenty of extensions which allow you to manipulate the DOM (document object model) via AJAX (asynchronous Javascript and XML) or similar, it is messy. XAML, on the other hand, is designed to be a user interface for applications, whereas HTML was just designed for static pages. This means that you don’t need to spend so much time mucking about with code to manipulate the DOM when you want to make changes to a page. Of course, AJAX frameworks will do a lot of that for you, but there are usually some complications at some point along the way, especially when things go wrong.
One of the big issues of course is browser compatibility. Apparently (according to Wikipedia), XAML can be rendered in some browsers (Internet Explorer and Firefox at least) with no plugin, as long as .NET 3.0 is installed on the PC with the browser in. For other browsers, the Silverlight plugin is available to deal with the XAML. On non-Windows platforms, Microsoft have released a plugin called Moonlight to deal with it.
I’d be interested to have comments from what other people’s experiences of Silverlight, XAML and WPF have been like and whether you’d like me to post more about any or all of these subjects.
ASP.NET Sessions Part 6 – Abandoning a Session
Friday, March 13th, 2009This entry is part of a series, ASP.NET Sessions»
If you want to terminate your session and effectively wipe out all variables in it, call Session.Abandon(). Although you can reset your session variables back to Nothing, this will also notify ASP.NET to clear the session up and call the event handler in Global.asax to deal with the session end (I think that this is the only way that this ever actually gets fired, but I could be wrong).
Entries in this series:
- ASP.NET Sessions Part 1
- ASP.NET Sessions Part 2 - accessing session state variable data
- ASP.NET Sessions Part 3 - Maintaining the Session Data Across Multiple Requests
- ASP.NET Sessions Part 4 - Configuring how the Session Variable Data is Stored on the Server
- ASP.NET Sessions Part 5 - How Long Does a Session Last?
- ASP.NET Sessions Part 6 - Abandoning a Session
ASP.NET Sessions Part 5 – How Long Does a Session Last?
Thursday, March 12th, 2009This entry is part of a series, ASP.NET Sessions»
Bearing in mind what I posted in earlier parts of this series of posts on sessions, you may find that other factors cut short your users’ sessions – see the earlier posts about this.
You can set the timeout of your sessions using the “timeout” attribute of the “sessionState” element in web.config. This is a value set in minutes, and is the idle time before a session expires. That means that the time is measured from the last request (not sure if it is measured from when the request is started, completed or some random point in the middle). It isn’t measured from the start of the session or anything.
The maximum value is 525,600, which is the number of minutes in a year (assuming it is a non-leap year). This maximum value apparently only applies to the in process and state server modes (I’ll be amazed if anyone manages to keep a session going that long in either of these modes without dedicating a server to it!).
The default value is 20 minutes.
Note that changing this has absolutely no effect on classic ASP sessions – they operate completely independently. I’m pretty sure nothing in web.config will ever really affect them.
Entries in this series:
- ASP.NET Sessions Part 1
- ASP.NET Sessions Part 2 - accessing session state variable data
- ASP.NET Sessions Part 3 - Maintaining the Session Data Across Multiple Requests
- ASP.NET Sessions Part 4 - Configuring how the Session Variable Data is Stored on the Server
- ASP.NET Sessions Part 5 - How Long Does a Session Last?
- ASP.NET Sessions Part 6 - Abandoning a Session
ASP.NET Sessions Part 4 – Configuring how the Session Variable Data is Stored on the Server
Wednesday, March 11th, 2009This entry is part of a series, ASP.NET Sessions»
ASP.NET gives you several alternatives for how the session data is stored on the server (remember that the clients just get a key to uniquely identify their session – not all the information is stored on their machines in cookies or anything).
- In Process
- State Server
- SQL Server
- Custom
These can be set by using the “mode” attribute of the “sessionState” element.
The “InProc” value (in-process) means that IIS stores the session state information within memory in the process that it uses for running the applications. This is the default setting and is ok for many situations, but it has some big downsides. All sessions are reset when the IIS process is recycled, which usually happens pretty randomly. Also, all sessions are reset if you do a major rebuild of the site (which can be more of a pain than you think, especially as ASP.NET might do this behind the scenes if you change something in the App_Code folder). The main advantage is that it is easy to configure and works out of the box. Another advantage is that the data in the session state variables doesn’t have to be serialisable.
The “StateServer” value means that ASP.NET should look in the “stateConnectionString” attribute to find a connection string to connect to an ASP.NET “state server”. A state server is a service which comes with ASP.NET (it doesn’t run by default – you’ll need to start it up and set it to run automatically when Windows starts). You can find it in the folder %windir%\Microsoft.NET\Framework\VersionNumber\aspnet_state.exe . Note that this doesn’t need to run on the same machine as IIS is running on, but it is probably sensible to run a state server of the same version as the version of IIS. I’ve never used this myself though, so I can’t tell you how well it works. The default connectionstring is to connect to the current server. I expect that this will need data to be serialisable and will be able to retain the data as long as the sessionstate service isn’t restarted (even if IIS is). It won’t retain data if the sessionstate service (or the whole server that it is running on) is restarted though.
The “SQLServer” option is my favourite. This looks in the “sqlConnectionString” attribute for a connectionstring to an instance of SQL server which is configured for storing session state information. ASP.NET 2.0 also added the “allowCustomSqlDatabase” element, which can be used to specify whether to use a customer SQL database instead of the default one. nb. You’ll need to setup SQL server for this, which you can either do by running the SQL script %windir%\Microsoft.NET\Framework\version\InstallSqlState.sql or by using the Aspnet_regsql.exe utility to do it for you.
The “Custom” value allows you to specify your own class which is responsible for storing state information. You’ll need to also add it to the providers section within the sessionState element and set the “customProvider” attribute to the name of the provider type. Your custom class will need to inherit from SessionStoreProviderBase.
There is also another value – “Off”. This turns off session state information being stored at all.
Entries in this series:
- ASP.NET Sessions Part 1
- ASP.NET Sessions Part 2 - accessing session state variable data
- ASP.NET Sessions Part 3 - Maintaining the Session Data Across Multiple Requests
- ASP.NET Sessions Part 4 - Configuring how the Session Variable Data is Stored on the Server
- ASP.NET Sessions Part 5 - How Long Does a Session Last?
- ASP.NET Sessions Part 6 - Abandoning a Session
ASP.NET Sessions Part 3 – Maintaining the Session Data Across Multiple Requests
Monday, March 9th, 2009This entry is part of a series, ASP.NET Sessions»
In order to maintain the data on the server across multiple requests by the same user, the server needs some way of identifying the user.
You may think that this can be done by IP address, but there are a couple of problems. Firstly, there is no guarantee that people are going to have a constant IP address – they may have multiple internet connections and a load-balancing router which will share their requests out among the different connections (this is becoming more and more common). Secondly, they may be accessing the internet via a common invisible proxy server or a common NATed router which will mean that multiple users may appear all on the same IP address.
That means that we need to find another solution. ASP.NET provides us with 2 alternatives. We can use cookies, or we can use unique URLs (web addresses) with a session key encoded in them. By default, ASP.NET uses cookies, but not all clients support them (some paranoid system administrators turn them off). ASP.NET also presents us with an automatic mode, which is designed to detect whether cookies are available and if not, encode the key in the URL. In my experience, this doesn’t always work.
The other problem with encoding the key in the URL is that ASP.NET can’t always reliably rewrite all URLs. It works pretty well, by encoding it as virtual directory, but this looks messy, and of course it creates problems if people bookmark the URL. It also loses the session if the user clicks a link which takes them to another site and then the site sends them back, or if the user retypes the original URL.
The sessionState element in web.config has an attribute called “cookieless”, which can be used to control whether cookies are used.
If it is set to “AutoDetect” (I think this is default), ASP.NET attempts (not reliably in my experiece) to detect whether the connecting browser supports cookies and use them if possible or if not fallback to URLs.
If it is set to “UseCookies”, ASP.NET will always try to use cookies, but they might not work.
If it is set to “UseDeviceProfile” (I think this is new in .NET 3/3.5 – not sure), ASP.NET uses System.Web.HttpBrowserCapabilities to try to find out whether the browser supports cookies. MSDN seems a little hazy on how this works exactly, but I would guess that it is via the headers that the browser passes in the page request.
If it is set to “UseUri”, ASP.NET will always use URLs, irrespective of whether cookies will work. I have had to use this setting at least once.
From ASP.NET 2.0, you are able to specify the cookie name if you are using cookies (it defaults to “ASP.NET_SessionId”) by specifying it in the “cookieName” attribute.
If you aren’t using cookies, there is also an optional boolean attribute called “regenerateExpiredSessionId”, which can be used to control what happens when a user comes back after the session has timed out with an old session ID.
Entries in this series:
- ASP.NET Sessions Part 1
- ASP.NET Sessions Part 2 - accessing session state variable data
- ASP.NET Sessions Part 3 - Maintaining the Session Data Across Multiple Requests
- ASP.NET Sessions Part 4 - Configuring how the Session Variable Data is Stored on the Server
- ASP.NET Sessions Part 5 - How Long Does a Session Last?
- ASP.NET Sessions Part 6 - Abandoning a Session
Windows Forms DateTimePicker ShowCheckBox and not Checked bug in .NET 2.0
Monday, March 9th, 2009I recently upgraded a project that I had inherited from another programmer to .NET 2.0. Shortly after, I received an email complaining that a date field had stopped saving correctly. I tried it out, and all looked fine in the user interface, but sure enough, the value was not being written to the database.
It took me some time to work out what was going on. The ShowCheckBox property was set to False, but the Checked property also was. For some reason, the DateTimePicker in .NET 2.0 interprets this as meaning that the value that is in the control is to be ignored, and it returns today’s date if you access the Value property.
This was a pretty simple fix – all it took was to set Checked to True, and it all worked fine again. It is an interesting gotcha to look out for though – I haven’t seen it documented anywhere as a breaking change of .NET 2.0
Phoneticise
Thursday, March 5th, 2009I wrote a little utility site at http://www.phoneticise.com or (http://www.phoneticize.com if you are American) a while ago. It was partly to test out Mono running on Linux and partly because I thought it might be useful to people sometimes, especially in call centres and places where you need to spell words out over the phone.
Bullet Point Indentation on TextControl
Thursday, March 5th, 2009I use TextControl .NET for a lot of the programs that I write – it is a great word processor component and works well for document based reporting as well. However, there are a few niggling little bugs that annoy me. One of them is bullet point indentation.
I discussed this problem with the technical support people at TextControl and they said that I would have to write some code to catch the Changed event.
I initially thought that this was a problem with the bullet point indentation itself, and then I noticed that if I added bullet points and removed them, the paragraph jumped back to 0 (default indentation is usually 500).
After a bit of playing about, I discovered that I needed to change the selection’s paragraph format properties for left indent and hanging indent as follows: -
Private Sub tcEditor_Changed(ByVal sender As Object, ByVal e As System.EventArgs) Handles tcEditor.Changed If tcEditor.Selection.ParagraphFormat.LeftIndent < 500 AndAlso tcEditor.Tables.GetItem() Is Nothing Then tcEditor.Selection.ParagraphFormat.LeftIndent = tcEditor.Selection.ParagraphFormat.HangingIndent + 500 End If End Sub
This might look a little odd, but in order to set the left indent to the correct value, it needs to be 500 greater than the hanging indent in order to get the correct behaviour