A colleague of mine just showed a great complete reference for threaded programming in C#. Since the article is great, I would like to share this one with the world. Here it is: http://www.albahari.com/threading/.
Cheers!
A colleague of mine just showed a great complete reference for threaded programming in C#. Since the article is great, I would like to share this one with the world. Here it is: http://www.albahari.com/threading/.
Cheers!
Hi folks,
I recently discoverd that by the end of February 2011 Red-Gate stops providing Reflector for free. Although their reason sounds obvious (they cannot work for free), I think many developers still rather prefer a free IL deassembler tool. Luckily, Scott Hanselman twittered about free open source alternatives. Those open source alternative IL deassembler projects are both based on the Mono Cecil project.
I would hereby like to share them with you:
Happy coding! Cheers!
PS. Of course I am very much interested in other free alternatives. Please post your comments if any …
UPDATE 04/27/2011: On Twitter I heard @dotnetreflector say to @haacked that they are releasing Reflector v6 with no expiry date for existing users in May 2011! http://bit.ly/eW3D7O.
It has been a while, but here I am again … I am currently working on an old Visual Studio 2005 solution. This bugger used to be built by a build server, but that one died about a year ago. Since some bugs really needed fixing, I decided that I would build the project myself for the moment.
Problem was that the solution uses WIX 3.0, and I have WIX 3.5 installed on my machine. After converting the WIX projects I expected the project to build without any problems. Unfortunately, however, WIX crashes with the following error: error LGHT0001: Unable to load DLL ‘winterop.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E).
After some searching on the web I found a post (not entirely my problem) with the searched solution: add the installation path of WIX to the Path variable. After this workaround everything works like a charm. Hope this helps you too !
Happy coding!
It has been a while since I last posted a technical post. I’m sorry, but I am too busy enjoying my work to keep you posted as much as I should.
Just a few days ago I was playing around with YSlow and PageSpeed, two add-ons on Firefox. Both stated my Javascript files were 1) to many and 2) not at all at minimum size.
Searching for an automated way of cleaning up and minifying my Javascript files, I bumped in on JSMin, a Javascript minifier that can be downloaded in C#. Do you hear the term HttpModule in your head already as I did?
When you try to implement JSMin, do consider the fact that your Javascript files will be stripped really rigorous: some of my files did not work anymore after minifying. The reason for this is that Javascript gives you the opportunity to write bad code. To prevent myself from writing rubbish Javascript files that fall apart using JSMin, I now use ‘the tool that hurts feelings’, JSLint. It hints you about bad code and, when obliged to, prevents you from failure when using JSMin afterwards …
Lucky coding !
Are you also fond of using the using statement (e.g. when dealing with streams)? I am, since it kind-of guarantees me that streams are closed when I think they should be closed, even if I do not specify the Dispose() command. You probably noticed the ‘kind-of guarantee’ part. You are right, this is not always the case. It took me a while to find out the the following is not going to work as smooth as expected:
using (var reader = XmlReader.Create(File.Open(fileName, FileMode.Open))) { ... }
You probably wonder what’s the problem of the code printed above. I don’t see it too, however, I know there is a problem related to this code. The problem lies in the Create overload used in the example code. It uses default XmlReaderSettings. Unfortunately, this settings do not include having the CloseInput property set to true. You can do the math: no closed file at all! That’s a guarantee for having troubles on the file ‘being in use already’.
The solution to this problem is quite simple:
using (XmlReader reader = XmlReader.Create(File.Open(path, FileMode.Open), new XmlReaderSettings { CloseInput = true })) { ... }
How can we call this? A ‘bug’? No, at least not technically spoken. Since the XmlReader creates the stream, it should close it too. The case is, you should not expext it knowing the using statement as most people know it (fail-proofing your code). Since I know this, I am a little bit scared about using using statements without calling the stream’s constructor. You can do so, but be sure it does what you expect it to do… In my opinion, the using statement still remains very helpful, please I do not consider it being as perfect as I thought it to be for years …