Share source files between Visual Studio projects
After some time developing software you naturally start to repeat yourself and solve the same problem over and over again. If you could simple share this implementations between all your solution’s, you would save a lot of time. On common way to share source code between different project is to create separate tool/”good to have code” assembly and simply include this project or assembly into every solution. Many times I find this very heavy weighted and overkill. But the big problem according to me is that you have expanded the attack surface of your application, by adding public API’s that you are not using but can be used by hackers. So the other solution is to simple add the part you actual need to your solution. By adding the source file as linked resources, will enable you to share it between many projects and still maintain only one copy of the file.
Another good example of usage is if you for example are creating an application for both windows phone 7 and windows. In this case you need two separate projects for every class library.
In Visual Studio, choose ‘Add As link’ when adding an existing item.
Get all iteration paths in TFS programtically
A common way to organize work items in TFS is to assign them to different iterations. I’m using this with the scum model where every sprint corresponds to one iteration. So how can we get all iteration paths in TFS to use them in our own implementation. The information is not saved on the work items, we will need to look directly at the project object and recursively iterate on the iteration object tree to get all iteration paths.
Example project
In this example you will be able to connect to a TFS server and get all work items based on project and iteration path listed.
Read more
Free options for Reflector (.NET decompiler)
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.
JustDecompile
http://www.telerik.com/products/decompiling.aspx
Feature
• 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
Read more
Scrumy Beta v1.0.7 is released
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
Message box that can center on parent form
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.
Remove ALL CAPS menus in visual studio 2012
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
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General\SuppressUppercaseConversion
REG_DWORD value: 1
How do you define a good installer?
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.
The pain of .NET “AnyCPU” build typ for installers
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
How to combine Split files in Windows
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
VS 2010 & .NET 4 Beta 1 is available now
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.