The obvious answer is when it’s 6th February (YYYYDDMM format) but there’s another much darker answer that I discovered today.
http://groups.google.com/group/google-visualization-api/browse_thread/thread/1c6ddcfd98dc9803/9a1ab79782bc5118?hl=en&lnk=gst&q=annotated+timeline#9a1ab79782bc5118
After having a look at the Google Visualization API, it turns out that JavaScript treats months as zero based rather than one based, it turns out that new Date(2009, 06, 02) is actually the 2nd of May. It makes sense if you then have an array of strings and want to easily convert from one to the other, but it’s useful information to know as it’s not the most obvious thing in the world!
The internet is a fantastic place to go and ask people for help with pretty much anything you’re stuck with. There are 2 resources that I’m rating quite highly at the moment for programming and IT related questions. The ideas behind the sites are fantastic, the people implementing them understand the system from both a developer’s perspective and a user’s perspective, and the user base for both is growing rapidly.
I won’t say anything more on them for now, aside from to give you their links: StackOverflow and it’s sister site ServerFault.
I’ll warn you though, they’re addictive once you start answering questions!
Being a .NET developer, I spend a lot of time in Visual Studio (I changed the default shell in Windows once from explorer.exe to devenv.exe for a while, but that’s another story!) and, like all major software products, it has a few bugs in it here and there.
One of these bugs that gets annoying very quickly is that every once in a while it will stop updating the designer.cs file for an ASP.NET page.
A little bit of background on this first though. When you create an aspx page in Visual Studio, you’re given 3 files. One for the markup that you write, one for the code that you write, and one that VS generates to allow you to use the controls from the markup in your class. At compile time, the 2 code files are combined in to one class, and then the page gets compiled on first run into a class that inherits from your previous class. It is not the same class as the one you created. This is important to remember, because not every control that you have declared on the page needs to be in the code-behind file. The runtime will create any controls that are in the markup whether they have any supporting code or not. While this may seem like a good feature, it just makes it harder to analyse and debug this problem!
Say you have a page with some controls on it, and you add another textbox or 2. All of a sudden, for no apparent reason, you can’t access these textboxes from the code behind file. They don’t exist and even when you type their names in it fails to compile. What do you do then? Restarting VS doesn’t seem to do anything, even restarting Windows doesn’t fix it!
There’s some questions on StackOverflow about this, so I’ve tried all of the different tricks. The one that seems to work consistently (and so has my upvote) is 1) Change into designer mode, 2) make a change (just modify some text or something) 3) save the file.
I’m hoping that knowing this saves everyone as much time as it’s going to save me!
I think Live Mesh is great. I’ve been running it since the day it hit public beta, and have 20gb worth of files spread across many computers and normally it works flawlessly…
…Having said that, this amused me today
I’m not sure what the right answer is… but I’ll probably get it wrong anyway!
Generics are amazing, and like a lot of things in life are pretty easy to use in the standard scenarios. It’s when you start doing clever things with them that things start falling apart slowly.
I was greeted today by the error message “The type or method has 2 generic parameter(s), but 1 generic argument(s) were provided. A generic argument must be provided for each generic parameter.”
Sounds nice and straightforwards, and as this is a compiler error, it gives you the file and line number where the problem occurs right? No! The error message is telling me that the error is occurring in our UnitTest project… where there are no generic types defined whatsoever.
It turns out that we had a private acccessor set up for one of our assemblies. For those of you that haven’t seen it, a private accessor is a utility used to test private and internal class members. It creates a stub of the class you want to test, and uses reflection to call the class’s private methods.
I haven’t managed to find a way round having one of these accessors, but as we weren’t using it I removed it and everything compiled and ran fine
In the spirit of Microsoft releasing betas of the Windows Live Suite (
Wave 3 of messenger et al) and there not being a mobile version of Live Writer, I've started hunting for one. Currently trialling the free "
Diarist" from
Kevin Daly.
As a quick review, it's simple and effective. Nothing gets in the way, and it supports a wide range of blog engines. Whether this post appears will be an indication of whether it works or not! ;)
I'm going to use it for a bit and see how it fares.
System.IndexOutOfRangeException: Probable I/O race condition detected while copying memory. The I/O package is not thread safe by default. In multithreaded applications, a stream must be accessed in a thread-safe way, such as a thread-safe wrapper returned by TextReader's or TextWriter's Synchronized methods. This also applies to classes like StreamWriter and StreamReader.
at System.Buffer.InternalBlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
at System.IO.StreamWriter.Write(Char[] buffer, Int32 index, Int32 count)
at System.IO.TextWriter.WriteLine(String value)
at System.IO.TextWriter.SyncTextWriter.WriteLine(String value)
…
This error had us stumped earlier this week. It was appearing on some of our asp.net pages, but not others, and only on one server in the cluster. It was consistent though, and very easy to reproduce. After taking the server out of the load balance cluster to diagnose it, we found out that the error was consistently appearing where people had used Console.WriteLine() methods for debug code. You might be wondering why you’d want to be using this command in an ASP.NET solution, but the output is sent to the output window if you’re debugging it from within Visual Studio. However, the error was new, the servers were working fine 10 minutes ago.
On closer examination of the server, it appeared that a session was left logged on, and there was an error message in said session:
SmLogSVC terminated at 0x7c81a379 while trying to write to 0x0000008. It seems that this is part of the WMI service and takes care of some of the logging / console output.
Upon clearing this message, the webserver was up for taking requests again and carried on happily! It went off to join the load balancing farm, and lived happily ever after! My only tips for avoiding this are to not leave terminal sessions logged on to servers, as then services are allowed to restart properly if they crash.
So, Visual Studio 2008 SP1 came out the other day, and with it brought .net 3.5 SP1. I’ll leave you to read the shiny new features and what it brings from elsewhere. The purpose of this post is to deal with the failure to update or install certain ClickOnce applications.
With ClickOnce being a under-advertised feature of the .net framework, nobody really published a changelog of what’s new in it. I’ve managed to dig this up though, as it became quite necessary to fix the above error. So I’ll refer you to this link which contains some hints.
ClickOnce supports the following new features:
- Suite Name: Your applications can now have sub folders on the start menu
- Error URL: Not used this one specifically, but I’m guessing when something goes wrong during deployment your users can be directed to this URL
- Creating Desktop Shortcuts: Fairly self explanatory
- Excluding a file from having a hash generated: Means that this file won’t have it’s download verified
- Clear Sign the package: Means that anyone will be able to update your app without having your private key (snk file)
So if you use any of those features, your users will require .net 3.5 sp1 installed on their computers. However, instead of prompting them with this useful message, they will receive an error telling them that System.Data.Entity cannot be found.
You can get round this by either not using the new features, or by marking .net 3.5 sp1 as a pre-requisite in your ClickOnce manifests
Doesn't require UAC to be enabled either!
Go Fetch!
I was sifting through the hundreds of spammers that have left comments on my blog pointing me in the direction of certain... 'enhancing' medical products and as I pushed "delete all" I noticed that there was actually a legitimate comment in there! Unfortunately I pushed delete on the comment and it vanished forever into the ether. So I dug back through the email notifications and retrieved it.
Buck Hodges : I'm curious to know what's missing from TFS 2008 Build that would make you choose CC.NET over the CI support we provide
The short answer to that is before we migrated to TFS we were using SourceSafe and were using CC.NET on that. When we migrated over to TFS we left our build server as it was and just re-pointed the source control repository. We've built up a set of scripts to deploy the database, website and workflow engine, and it wasn't deemed important enough to switch build servers.
So it's not really a case of what's missing from TFS 2008 Build, it's that we're not missing anything TFS Build 2008 has to offer! :) (And at the moment, if it aint broke, don't fix it)
Thanks Buck
We make use of continuous integration on the project I'm on at the moment. A summary of Continuous Integration (for purposes of this post) is that there is a dedicated computer set up that is constantly checking out the latest version of the source, compiling it, and running a comprehensive set of unit tests and regression tests against it to make sure that we're not breaking existing functionality.
In addition to this, we also deploy a nightly build to a webserver (with this being a web application) that can be tested manually. If testing on this goes well, that release will make it into a testing environment including having exposure to some end users for constant feedback on the progress of our development. These releases (which I'll incorrectly label "UAT Releases" for the purpose of this post) will sometimes contain bugs that can be fixed quickly with a patch. To do this we create a branch from the release code, merge the change into this branch, build, test and then deploy that release... or so we thought!
Even though we've got Team Foundation Server installed, we're using Cruise Control .NET for our build server. Because of this, the process isn't quite as integrated as it could be. We check out the latest version of the source, build it, run the unit tests, if all those are successful we update the assembly version numbers in Assembly.cs, check that back in and then apply a label with the current build number. Seems like a nice straightfoward thing to do, and it works perfectly for a nightly build. Now some of you out there will have spotted the problem with this... those of you that haven't, it's to do with how long this process takes, and the fact that on a nightly build no one is checking stuff in at that time of day.
Yes, as soon as we started doing these during the day, we found that what we were labelling was in fact slightly different than what we were building (or not so slightly, depending on the size of the checkin). Our major problem here was that our action wasn't atomic. If someone did a checkin between our initial checkout and our labelling, their changes were included in the label. As building and testing the project can take between 30 and 60 mins, this is quite a big window during the day.
Our resolution for this was to label the branch *before* doing the checkout, checking out the label, and deleting the label if the build failed (in essence rolling back our changes). Due to the way TFS handles labels, we could check in Assembly.cs with the updated build number and get it included in the label for if we decide to branch from it to patch it or reproduce issues.
Subversion has a lovely little utility called "Blame" which will show you who modified a line of code and when, so you don't have to trawl through the history or the file looking to see when a line was changed. I've always thought that this was a feature that TFS could do with... until now.
It turns out that TFS already has this, but the guys at Microsoft have given it a rather more subtle label of "Annotate". Click on this and all of a sudden the file gets decorated with who checked in which bits and when! Then you can find out who to blame quite quickly! ;)
I started a series over a week ago about the new language features in C# 3 and the capabilities of version 3.5 of Microsoft's .NET framework. This post is designed to act as an index post so you can see what has been posted and what is yet to come! :)
Extension Methods and Interfaces
Anonymous Methods
Lambda Expressions
Implicitly Typed Variables
Anonymous Types / Object Initialisers
Iterators
(Partial Methods)
Query Methods
LINQ
So I digress a little bit. Anonymous methods were new to C# 2, not C# 3. However, they aren't in common use so I thought I'd go into explaining them here, as they are fundamentally important on our journey of learning LINQ.
So as a developer you're familiar with the concept of methods. Named Logical blocks of code that are grouped together, can take input parameters, do stuff, and return values.
The definition of "Anonymous" (according to Merriam-Webster) is "not named or identified".
So we can see here there's a bit of a conflict... although it's not as difficult as it looks! :)
We go from the following well established piece of code:
...
this.button1.Click += new EventHandler(button1_Click);
}
void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("Test");
}
to our new Anonimised version:
this.button1.Click += delegate
{
MessageBox.Show("Test");
};
It's important to realise here that Anonymous methods are purely syntactical. They still compile down to real methods. In this instance opening up Reflector (amazing tool, no one should be without it) shows that the anonymous method has been (rather imaginatively) named <.ctor>b__0. It's called from the constructor and behaves just like a normal method. They can be useful to keep code close to where it is used (in the example of keeping it near the definition for the button in this case) and also for multithreading purposes:
void StartThread()
{
System.Threading.Thread t1 = new System.Threading.Thread
(delegate()
{
System.Console.Write("Hello, ");
System.Console.WriteLine("World!");
});
t1.Start();
}
The above example prints "Hello World!" asynchronously on the command line
They have more uses, as we'll find out later! :)
---
Extensions methods are a new language feature of C# 2 and require .net 2.0 to function
I'm quite a fan of extension methods. For those of you that don't know, extension methods allow you to extend and add behaviour to classes or interfaces without having to modify the class itself. For example, if you are using strings to store telephone numbers (who isn't? :)) and you want to have some form of validation on them, your best bet is going to be to have a static helper class with a method in it that takes a string, performs the validation and then returns a boolean value. Then whenever you want to call it, it looks something like StaticHelperClass.IsValidPhoneNumber(phoneNumberToCheck);
That is until extension methods came along...
As far as the initial developer is concerned, not much has changed. You still need the static helper class, you still need the static method that takes the string, and you still return the boolean. The only difference is a single keywork: 'this'. Now whenever someone wants to use your method, they can just call phoneNumberToCheck.IsValidPhoneNumber;. So why are they useful? Initially, you can see that they lead to easier to read code, which in turn leads to code that is easier to maintain. They also play a key role as a building block of LINQ (more to come on that later).
This is one of the new features of C# 3, which I'm going to be blogging about over the next few weeks or so, and presented on at the free Black Marble Visual Studio launch event.
---
So, what does this have to do with interfaces? Basically, you can write your static method to take an interface rather than a concrete class, and all of a sudden you've got some code that follows that interface round wherever it goes! Makes code re-use a bit easier if you didn't have much control over the original implementation of the code base, as you can have code that's common to a particular interface in that rather than in an abstract class (eg if you are already inheriting from another class in some uses of the interface). This has a really good chance of being abused though, so be careful when you implement these!
---
Extensions methods are a new language feature of C# 3 but only require .net 2.0 to function
More Posts
Next page »