CodeMaid for Visual Studio 2012

I used macros often before Visual Studio 2012. Although it was awkward to write it in VBScript, it did the tricks. For example if you wanted to join two lines in visual studio, you could create the macro and assign a keyboard shortcut (I usually assigned ALT+J). Here is the Macros I used to join two lines. It worked like a charm.
 

Imports System

Imports EnvDTE

Imports EnvDTE80

Imports EnvDTE90

Imports EnvDTE90a

Imports EnvDTE100

Imports System.Diagnostics

Public Module TonyJiang

    Sub JoinLines()

        DTE.ActiveDocument.Selection.EndOfLine()

        DTE.ExecuteCommand("Edit.Delete")

        DTE.ActiveDocument.Selection.Insert(" ")

        DTE.ActiveDocument.Selection.EndOfLine()

    End Sub

End Module

 

Now macros are gone in Visual Studio 2012, which triggered me to bing if there were any options to do the tricks for me. It turned out that a pleasant surprise was waiting for me. I found www.codemaid.net, which owned the functionality of join two lines and much way way much more by pressing CTRL+M, J. But what really excited me was there were so much more functionalities to clean the code, such as sorting the using clause and adding endregion name etc. It was so cool that I would encourage for every .NET developer to install it. Solute to the developers of codemaid!

 

 

Code Cleaning

Cleanup random white space into a simple standard order. Add unspecified access modifiers. Utilize Visual Studio's built-in formatting capabilities. Remove and sort using statements. And do it all automatically on save or on demand, from an individual file to the entire solution.

 

 

 

 

 

Windows 8 Doesn't Woo Enterprise Users

Last week I attended an event hosted by Markus Egger about .NET and Windows 8 Developer know-how! I felt a bit of pressed to write something about it because I am concerned about Microsoft's strategy for one OS to combine metro and desktop. I don't question Microsoft can produce a stunning OS to compete with iOS + MacOS on consumer tablets market. If there is one company other than Apple on the earth, it got to be Microsoft. However, is it really a good idea to combine metro with desktop? Really? How soon will the laptops and desktops all have the touch screens? How about multiple monitors?

My concerns were mainly for enterprise users and how Windows 8 would roll into enterprise domain:

• Windows 8 customer preview doesn't provide the flexibility to configure WorkStation only or Metro mode only. I hope Microsoft will fix this. For enterprise users, there is no need to have metro mode. Windows 7 is a huge success. Windows 8 desktop mode didn't do much to improve it further. There will be a new windows explorer with ribbons panes for documents and library. The task manager will be revamped to have more information. So instead call the workstation windows 8, we can call it Windows 7.1. The good thing about the workstation mode is that it supports everything Windows supports before.

• Metro mode can run on ARM processors for power efficiency and long battery life. Microsoft appears not to want existing applications to run on ARM unless they are redesigned for Metro – though it says there will be a version of its Office suite for ARM systems. But there is No Office suite for Windows 8 metro mode. You have to use desktop mode to run office suite. How can you imagine the enterprise Windows users not use Office?

• There will be Two Version of IE(s). As a developer, I can foresee the compatibility issues just between these two versions of IE. According to Markus, one IE will run with System32.dll and the other runs on WinRT. One supports plug-ins (Flash and Silverlight) and the other will not. How the enterprise web site to adjust that? Does enterprise have to convert everything to HTML5?

• The metro mode will Not Support Multi Monitors. Can you imagine the user with multiple desktops to switch to metro style and see other screens blank. I am not sure if this is the final decision yet but it doesn't make senses to me if it is to-be-shipped "feature". We should not call Metra mode Windows. Instead I think Windows 8 should call it Window 8 (Windows without s).

• The metro mode has Limited Multi-Tasking Support. It makes sense for slate-and-touch devices because everything is running as full screen. Limiting tasks will save the power assumption. However, does it make sense for plugged in desktops and laptops? Especially for multi-monitor desktops. This is doesn't make sense for enterprise users.

• Deployment metro style application will be a chore. The only way to deploy metro application is through AppStore. I don't think this is very friendly for enterprises. Does enterprise will allow Microsoft check the source code before the application get approved to be added to the store?

• Xaml Compatibility is very low according to XAML Comparer Tools between WPF and Metro. It's about 20-% compatible between existing WPF and Silverlight xaml application (This tool allows for comparison of different XAML dialects and utilized framework namespaces. Want to know if your Silverlight project will translate well to Windows 8 Metro? And whether your Metro assets can be reused in your Windows Phone app? And how about that WPF app?)

• No Start Menu for workstation mode, really???

In the end, I have to come to the conclusion – Windows 8 doesn't have enough attractions for the enterprise users. It might be a huge success in consumer market. All the opinions are personal and based on what I got from the meeting. So they could be biased and not accurate.

We will see.

Configure NLog ColoredConsole

I like NLog because it is probably the easiest logging framework I used. By simply copying NLog.config file to the project and set the Build Action to Content, I can use NLog in my code now. NLog support ColoredConsole. However, the default color scheme doesn't seem to make sense to  me. Here is the example, you can see the Error level is yellow. The Debug level is the same white color as Info level.

Fortunately, it's very easy to configure NLog to use different color scheme. Here is the color scheme I used.

Error/Fatal level: Red

Warn level: Yellow

Info level: White

Debug level: DarkGreen

Here is the configuration file correspondingly.

  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <targets>
      <target name="console" xsi:type="ColoredConsole" layout="${longdate} [${whenEmpty:whenEmpty=${threadid}:inner=${threadname}}] ${level} ${logger} ${message} ${exception:format=tostring}">
        <highlight-row condition="level == LogLevel.Error" foregroundColor="Red" />
        <highlight-row condition="level == LogLevel.Warn" foregroundColor="Yellow" />
        <highlight-row condition="level == LogLevel.Info" foregroundColor="White" />
      </target>
      <target xsi:type="File" name="file" layout="${longdate} ${level} ${logger} ${message} ${exception:format=tostring}" fileName="${basedir}/logfile.log" keepFileOpen="false" encoding="iso-8859-2" />
    </targets>
    <rules>
      <logger name="*" minlevel="Info" writeTo="console" />
    </rules>
  </nlog>