Friday, August 21, 2009

BeginUpdate() and EndUpdate() when populating ListView/TreeView

Use of BeginUpdate() and EndUpdate() when populating ListView/TreeView

Often a listview control in C# needs to be populated with large amount of data (bulky operations, for example, adding 1000 items). For every item added in the Listview, the control will redraw itself, thus greatly reduce the overall performance.

However, using the two methods BeginUpdate() and EndUpdate() while performing these bulk operations gives significant advantage. A call to BeginUpdate() can be made before adding/deleting/clearing items. This will stop any paint messages being sent or processed. Once the operation is done, the EndUpdate() can then be called.

I have logged the time taken of the above code (i.e. adding 1000 items in a ListView for each button click) with and without the BeginUpdate/EndUpdate method calls using a test application.

The use BeginUpdate() and EndUpdate populates the control with a constant duration and much better performance. Amazing, isn't it?

SuspendLayout and ResumeLayou

SuspendLayout and ResumeLayout

The SuspendLayout and ResumeLayout are methods used in order to prevent conflict when events pertaining to placing and moving controls and setting their attributes are thrown.

You would for instance perhaps like to add controls onto a panel or a window programatically .. what you must do is suspend the control you are adding other controls to and after you are done adding ,you then can resume your layout by calling the ResumeLayout method.

say for example you have a panel and would like to add some controls to it here is how you would do it using a method :

private void AddSomeControls()
// Suspend the panel layout and add two buttons.
TextBox txtOne = new TextBox();
txtOne.Location = new Point(10, 10);
txtOne.Size = new Size(75, 25);
txtOne.Text = "Textbox addded";

Button btnMyButton = new Button();
btnMyButton.Location = new Point(90, 10);
btnMyButton.Size = new Size(75, 25);
btnMyButton.Text = "Just been Added";

this.Controls.AddRange(new Control[]{txtOne, btnMyButton});

Thursday, August 20, 2009

Always Ask for Reboot when installing Visual Studio .NET

You receive a "Setup has detected that another program requires the computer to reboot" message when you install Visual Studio 2005 or Visual Studio .NET

To resolve this issue, use one of the following methods.

Method 1: Modify the Windows Registry

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
  3. In the right pane, right-click PendingFileRenameOperations, and then click Delete.

    Note If the PendingFileRenameOperations value does not exist, exit Registry Editor, and then use method 2.
  4. Exit Registry Editor. Then, try to install Visual Studio 2005 or Visual Studio .NET again.

Method 2: Install the Prerequisites components from the Visual Studio 2005 or Visual Studio .NET CD

  1. Cancel the current installation.
  2. Insert the Visual Studio 2005 or Visual Studio .NET Prerequisites CD into your CD drive.
  3. Click Start, click Run, type drive:\setup.exe, and then click OK.

    In this step, drive is the letter of your CD drive.
  4. Click No when you receive the following message:
    Visual Studio .NET Prerequisites Warning - Setup on CD1 should be used to launch Visual Studio 2005 or Visual Studio .NET Prerequisites setup so that only the necessary components are installed. Click Yes to exit and change CDs. Click No to install all available components.
  5. After the installation of the Prerequisites components is complete, insert Visual Studio 2005 or Visual Studio .NET CD 1, and then install Visual Studio 2005 or Visual Studio .NET.

Wednesday, August 12, 2009

Localization of .Net applications

Localization of .Net applications

These last days, I had the change to mess up with the Localization infrastructure inside Visual Studio 2008. I must realize it´s the first time I seriously get into this issue, and I´m impressed with the work done on it.

When one needs to give an application multi-language support, the first temptation (as old-time programmers) is to build up some sort of tables with strings, each one for each language. That´s more or less what the Localization system will do, but with the following extra features:

A comfortable visual editor

We have a comfortable visual editor to manage the string tables, like this one, giving you the chance to set comments to each entry.


Culture infrastructure-ready

The system offers automatic integration with the Culture infrastructure of each application. To get more info about this, check:

  • System.Threading.Thread.CurrentThread.CurrentCulture
  • System.Threading.Thread.CurrentThread.CurrentUICulture

This gives you automatic support for different numbering and date formats, etc.

Integrated with the Visual Studio Designer

To start localizing, you just have to open the design view of a form or control and set the Localizable property of any form or control to True to generate the default resource (.resx) file. From then, each time you 51select a new language in the combo (and change any property), a newer resX file is generated to reflect the change. Of course, all this files are perfectly managed by the Solution Explorer as a part of the form or the control.

Once a form is localizable, each time we change the current language, the designer automatically updates the design view to show the appearance of the form or control in that language. ResX files are also maintained automatically.

Localization of the entire looking (not only texts)

You can make specific versions of each control or user interface for each language, including control positions, dimensions, colors, anything...

This is specially relevant because many times is not enough with just replacing texts. The translation of a text may have a remarkable different length in other languages. In this case we would have to resize the label containing the string, and maybe relocate other controls in the form, as in the following picture, where you can see two version of the same form, for two different languages.


Note: Text strings are saved directly in the resx files accompanying the Form1.cs class, but other properties, like dimensiones, locations, etc, are saved in other place. When you compile your solution, in the output directory you will find additional folders with culture-specific names, like “en-US”, etc. This folders will contain additional DLLs created automatically by VisualStudio, one for each localizable assembly. Inside this DLLs, you will find resources defining the appearance of the form´s controls.

Additional String Tables

We have talked about resource files handled by the Designer to reflect the appearance changes of forms for different languages but, what happens with the message shown in a MessageBox? This is not something we can manage in a design view.

A solution is to insert additional .resx files to the project. We can make them “embedded resources” and easily access them with the ResourceManager class directly, although I must tell you this is not the best solution (see next chapter). Of course, there´s no designer to handle this tables, so they will have to be maintained manually (using the visual editor).

To include a complete collection of additional string tables, you can start with the default resx file (for the default language). Give it any name you like, for example: “LocalizedStrings.resx” (just click your project with the right button, and select “Add New item”, and then “Resource File” as the item type). Afterwards, you can add any other language version for that file, using the same name with the culture-specific string representation before the extension. Some examples:

  • LocalizedStrings.en-US.resx

Strongly-typed access to string tables

This is also a very important feature, because once you have your string table up and running, you need to get access to it from your code. You can do so directly through the ResourceManager.GetString() method, but this is definitely not a good idea. Mostly because you will have to give it the name of the entry you are looking for, in the form of a simple "string”.

This means that you will have no Intellisense support (you will have to look the name of the properties in the table by yourself), and if any property name is changed later, there will be no compiling warning or error. This means that if you are not extremely careful for the rest of your application´s life, you won´t notice the mistake until runtime, and this is extremely bug-prone.

The solution is to make a strongly-typed class, which includes code properties to access each entry in the table. Of course, it would be a non sense if we had to make them manually (it would be the same as accessing though the ResourceManager class). Thankfully VisualStudio includes a tool to take care of such task: the ResXFileCodeGenerator. To make VisualStudio invoke this tool, you will have to put it´s name (“ResXFileCodeGenerator”, without quotes) in the Custom Tool property of the default resx file. This is important: IN THE DEFAULT resx file. This means that, if you have LocalizedStrings.resx (with the default language, spanish for example), and LocalizedStrings.en-US.resx, you have to set the custom tool to the first one.


When you do so, a new “.cs” file will be generated for you (below the resx file) containing the strongly-typed class. Though the maintenance of this class is automatic, you can force a refresh anytime you want by clicking the resx file with the right button and selecting “Run custom tool”.

From now, you can access your strint table texts with Intellisensed, strongly-typed, in-code properteties like:

“text = LocalizedStrings.strWarningCaption”

APPENDIX A: Making an automatically-generated, strongly-typed class to be PUBLIC

By default, strongly-typed classes generated with the ResXFileCodeGenerator tool are INTERNAL. This means that they will only be accessible inside your assembly.

To make one of this classes public, you cannot just change its code as it will be re-generated by the tool on next rebuild. You have to change the custom tool, selecting the PublicResXFileCodeGenerator instead of the previous one. It will make them public for you.

You can also do this “double-clicking” your string table (to enter the visual editor view), and selecting the PUBLIC modifier in the upper part of the screen (this actually changes the custom tool as explained above).

Well, it´s been long, but hope it helps someone. However, this is my first approach to Localization and therefore, for sure there will be people with deeper knowledge on this issue. Please feel free to complete (or correct) this tutorial with comments and suggestions.

Tutorial: Visual Studio 2008 Obfuscating with Dotfuscator

Tutorial: Visual Studio 2008 Obfuscating with Dotfuscator

In this
tutorial I'll teach you what Obfuscating is, why you should use it for your .NET products and how to do it with Dotfuscator. Dotfuscator comes with Visual Studio 2008 Professional Edition, if you don't have it you can still buy it as a standalone. Lets start by looking at what obfuscating is.

What is Obfuscating?
Obfuscated code is code intentionally (mostly) created hard to read, however, poor programming skills and/or little knowledge of standards can cause a programmer to create obfuscated code without even knowing it. There are some languages more prone to obfuscated code than others such as C and C++.

double h[2]; int main(_, v) char *v; int _; { int a = 0; char f[32]; h[2%2] =

682887858054616489605441589829740433065995076650229152079883597110973562880.0 00000; h[4%3] =

1867980801.569119; switch (_) { case 0: break; default: main(0,(char *)h); break; } }
Why Obfuscate?
Obfuscating can make code very difficult to understand or even reverse engineer. Programs written in .NET or Java are easy to decompile to full source code as though the cracker is looking at the original code you wrote in your IDE. These reverse engineering programs are freely available on the internet making it easy for anyone to see your entire source code. While still readable, obfuscating makes the code harder to read creating some security for your applications.

Getting Started
In this tutorial we will be obfuscating a the Visual Studio 2008 C# program we created in this tutorial:, however you can use whatever project you desire. We will use the debug build here.

Step 1
Load Visual Studio 2008 (Start/Microsoft Visual Studio 2008/Microsoft Visual Studio 2008). You don't have to select a project but VS2008 must be loaded before you can launch dotfuscator.

Step 2
Load dofuscator (Start/Microsoft Visual Studio 2008/Visual Studio Tools/Dotfuscator Community Edition). If you do not have VS2008 loaded you will see an error:

Step 3
You may be asked to Register. Click "No, I don't want to Register" or "Yes, Register Now", your option but this tutorial will not cover that. At the next screen, "Select Project Type", click "Create New Project" and press "OK".

Step 4
Click "Browse and add assembly to list" icon (below Input Assemblies: - the open folder icon). Click Browse. Navigate to your project executable file. Using the C# Hello World project you will find it located in "My Documents/Visual Studio 2008/Projects/HelloWorld/HelloWorld/bin/debug/HelloWorld.exe". Click "OK".

This image has been resized. Click this bar to view the full image. The original image is sized 600x430.

Step 5
Goto "File/Build or press Ctrl+B. You will be asked to save your project, press "Yes". Enter "HelloWorldC#" or a suitable name for your project. You should see:

Step 6
Your project has now been obfuscated. You can find the executable in "My Documents/Dotfuscated/HelloWorld.exe". This is the executable you want to package in the installation file, however, you will want to use a build release instead of a debug release. Click on "Output" tab to see what was obfuscated:

This image has been resized. Click this bar to view the full image. The original image is sized 600x430.

Originally Posted by afkhami View Post
so how do you package your software protected with Dotfuscator?
The Enhanced Community Edition will integrate with Visual Studio, letting you use the Dotfuscated project output for your Setup project's input.