After Reflector did change their licensing so it was no longer free to use I did stick around for a long time on an old version of Reflector. The time have now come to find an replacement for Reflector. After some searching I found 4 good candidates.
• Fast code navigation
• Create visual studio projects
• Extract resources from assemblies
• Easy assembly management
• Visual studio inline decompilation
• Command line support
• Integrate with Windows Explorer Context Menu
• Silverlight XAP decompilation from URL
The big change in this release is an improved UI for changing the layout of the printed items.
The release can be download here: http://scrumy.codeplex.com/releases/view/100750
When using the built in MessageBox class to show message you are not able to center the dialog based on the parent form. This leads to that the dialog normaly popup in the center of the screen even if the application it’s executed only cover the upper right corner for example. The solution is simple to create our own MessageBox clone with this added functionality. I was also missing a possibility to show a self closing message. So I could for example give the user 10 seconds to respond to the message, after that I would simple close the message dialog and use the default response.
One of the first thing I did change after install VS 2012 was the upper cases menu. I find it harder to read menu options that is always upper case. So here is the trick.
Start regedit and add this key to change to VS 2010 behavior
REG_DWORD value: 1
Did read Christopher Painter blog “Back To Basics – Installation Principles” today. It contain some very basic rules of creating an installer. In his blog he lists 14 point of what to avoid and what you installer should do to be a good installer? I have personally seen big problem rise from his advice number 12 about using standard installation part and avoid using you home maid as much as possible. So to make it short, I think every installer developer should really look into this list to avoid doing the same mistakes.
And here is the list copied from Christopher.
1) Remember that your install is the very first impression the user gets of your application. If your install sucks or worse fails that will not want to use your software or your support desk will get flooded with calls. I can not understate this point. I have saved companies from the brink of bankruptcy by fixing their deployment problems and I’ve seen companies fail that were unwilling to take their problems seriously.
Today I found an interesting post about why we should avoid using “AnyCPU” as build type when we are building managed assemblies. The problem simple is that when installing the application and are writing registrie key we need to define if it’s a 32 bit or 64 bit application in the MSI. You can build an EXE as “AnyCPU” and on an x86 windows machine it will run on the 32bit CLR and on an x64 windows machine it will run as a 64bit process.
Christopher Painter gives this example on his blog post to explain the problem:
So let’s start with a simple example. Let’s go back 10 years in time and pretend we are writing an x86 application and x86 installer with no concern for x64. Someone hands you a vb6 EXE and a regfile ( HKLM\SOFTWARE\Company\Product type entries ) and says this is what needs to be deployed. You go off and create an MSI that writes the registry values, deploys the EXE and creates a shortcut. Now let’s come back to present. You take that MSI and throw it on a modern Windows 7 x64 box and it works just fine.
But now let’s pretend that the EXE was a .NET application. If it was compiled as x86 it would behave the same way. But if that application was built at AnyCPU ( the default for all versions of Visual Studio prior to VS2010 ) we are going to land in one of those traps. Here’s why:
MSI is marked as an x86 package so it writes the registry data to the Wow6432Node of the registry so the expected x86 application can find it. While the EXE gets installed to ProgramFiles(x86) it will actually JIT as a 64 bit process. This process will fail to find it’s registry resource at runtime and crash. This is because the .NET BCL Win32.Registry class cares about bitness.
You can find his complete post here
Last weekend I did some cleanup of my Linux machine and transferred all files over to the Windows machine. I ran into problem to transfer bigger files than 4GB so I needed to split the files before transfer and put them back together in the windows machine.
To split a file in Linux to 100MB per piece write:
split –b 100m /path/to/large/file /path/to/output/file/prefix
To put them together again on windows write in the command prompt
copy /b /path/to/output/file/prefix* files.tgz /b
Here is the link to the Beta 1 page : http://go.microsoft.com/fwlink/?LinkId=151799
This is page has a ton of Beta 1 resources such as the Download links, ‘How to download’ video, training kit, walkthroughs, forum links, MSDN library links, featured blogs and link to Connect for bugs.
After been spending some tuff days with only reading about user cases and different deployment ways I have finally passed the windows MCPD exam. This is the exam that I think I did learn less from out of the 3 you need to get a MCPD for windows. It was a lot about user cases and testing that I did know most of it already trough my work and universities studies. So I guess the exam was more for people that would like to have paper that they know this things of have not any university degree in computer science.
Found a really interesting blog by Michael Feathers today. His goal is to get every programmer from different background up to minimum knowledge bar. The blog contain link to good papers about best practice and other thing a programmer should know as how programming language works.