What .NET Framework Version am I running?
Someone on the Stanski mailing list recently asked about a particular version of the .NET Framework (v1.1.4322.2379 which seems to almost be MIA and almost no useful information on Google). What came out of the conversation are a couple of applications/tools.
The first is a free .NET version checking utility which the guys across at TMG Development have built. On their download site they also have a quite comprehensive list of the different framework versions (although the mysterious version is missing from that list too).
Early this afternoon I also came across a Microsoft site that will inspect the current version of a dll and provide you with information about what the dll is, when it was shipped and in which packages it was included – this might some day be useful so I figured I’d keep a reference to it here.
Just a reminder about a couple of events:
Perth .NET Community of Practice has its monthly meeting at the Excom Training Centre @ 5:30pm – Don’t miss Stephen Price talking about the Expression Suite. Also, if you haven’t already, make sure you subscribe to the user group announcements feed here. We will continue to send out email reminders prior to each monthly event but this feed will contain other information about what’s going on in Perth etc.
Slides for Dave sessions are now available here
The Australian Computer Society Young IT (WA) committee are hosting an “IT in the Pub” event from 6pm tomorrow evening. Check out my earlier post for more information.
Don’t forget the weekly coffee fix on Tuesdays, 1:30pm @ Tiger Tiger – come and share your experiences, frustration with your peers. The food, coffee and service is fantastic and there is free wireless to boot!
The Mobile and Embedded DevCon is hitting Sydney next week (15th May). If you are in the neighboorhood I suggest you register today
TechEd 2007 Australia:
Early Bird (until 21st May) registrations are now open. This is definitely an event not to miss. If you haven’t already booked this in your calendar I’d suggest that you register now.
Single Instance by default with OneCare
Today has been incredibly frustrating. With Bill’s help I was able to work out some of the issues I was facing yesterday with regards to using the Single Instance Application feature in the VB Application Framework. Turns out that they use a secure channel and if you attempt to use an unsecure channel (ok, I know I should have been securing it but it was a prototype!) it fails.
The next problem I encountered was that the first time you attempt to establish a connection, OneCare (my current firewall product) would prompt you to say whether it should be allowed, blocked or just blocked this time. The ironic thing was that in the meantime the app had crashed in the background.
Going back to what the VB team did in building their single instance feature I created a very simple application (ie create new project -> Windows Application (VB)). I then enabled the single instance feature and ran the application. From the bin folder I tried to run the application again and BANG there goes OneCare again:
That I could live with but a second later (before I had a chance to select an option) I noticed:
Urgh – I’m not sure whether this is a bug/feature of OneCare or the VB Application Framework but I’m so not happy! Pretty sure this is an issue with OneCare as it shouldn’t be rejecting the connecting application until the user has selected whether the accept or block the application.
Funnily enough if you select to “Block for now and ask me again later” if you try to run the application again it just crashes without the OneCare prompt. I guess this is to be expected with a v1 product!
Update: Looks like this is definitely a problem with OneCare (and perhaps other firewall products). I disabled the OneCare firewall and instead enabled the standard Windows Firewall. The Single Instance test app works fine without prompting or failing. Although it is great that OneCare protects more than the standard Windows Firewall there is an issue (aka bug) that it is causing the client application to fail prior to the security prompt being dismissed!
Good job I own a Window Mobile phone!
As Brian posted there is a Microsoft for Partner Roadshow coming to Perth next week. Being a Microsoft partner [Intilecta] decided to go along to see what all the fuss was about…. Of course, this meant going through the online registration process. Interestingly it prompts you to enter the type of mobile phone you have:
But hang on, where are all the Windows Mobile devices? I know that the registration process is run by Info Salons but honestly Microsoft should really audit their service providers to ensure people who have invested in their technologies don’t feel like they have been left out of the loop.
Actually it wasn’t that remote but it was to do with .NET Remoting. I wasn’t trying to do anything difficult yet getting a simple scenario to work resulted in a number of hours of tearing hair out. In a test application the remoting call would work fine but when I embedded the exact same code into the main application it would fail stating:
No connection could be made because the target machine actively refused it
You’d think this was some security issue but I tried everything I could think of (and a few more thanks to Google) and to no avail. In the end I ripped the solution apart – it turned out to be something wrong in the .suo file. Delete this file and I was good to go – ARGH!
The next issue I came up against was when I had changed a few things in the client application (the app that was going to call into the server application where the remote object had been instantiated). All of a sudden I was getting the following:
An existing connection was forcibly closed by the remote host
Now someone else has previously experienced this same issue and it turns out it might have something to do with the way that the VB team uses remoting to provide “single instance application” support in their application framework.
Building a simple send (ie client) and a simple receive (ie server) style application (which I had done earlier when trying to resolve the first issue) I tried enabling and disabling the “single instance application” feature on both sides. Turns out that it was only when I enabled this feature on the client application did I run into issues. This time I got the following exception information:
Inner Exception: “Unable to read data from the transport connection: The connection was closed.”
I haven’t had a chance to work out exactly is conflicting between this feature and the ability to use tcpchannel remoting. Hopefully when I have time I’ll get to the bottom of it.