Biz Tech-ThoughtWorks

Today, attended ThoughtWork's BizTech conference (web site at http://thoughtworker.com/events/biztech-live-chennai). Just wanted to share the knowledge what learnt.

Session had 2 topics, 'Agile & TDD' by Vijay and 'Formal methods' by Rajesh. Itz a wonderful techy day between 10AM and 3PM. Audience shot lot of interesting/sensible questions, which shows the quality of presentation. TW shares not only business benefits of Agile; but also industry growth (surprisingly) Inter sting topics are pair programming, test driven development, tech debt, story card, safety net, continuous improvement. Since, the model is contra with traditional development model, people asked the typical questions like pair conflicts, level of knowledge, project bidding, cost of ownership, project billing, extra person hours, etc . Answers were awesome!

As the result, I got better perception. My understanding is that there are two key success factors for ThoughtWorkers. (1) Organization culture (2) Attitude of Learn & Grow.

Hats off to Martin Fowler for building 1700 world class knowledge workers across the globe. In the current IT environment, Martin makes a huge difference in work culture to produce better quality and productivity. Inspired by his leadership.

No standard library

On working with every new versions of VS, itz quite interesting to have everything handy. As an example, you use FW class without its namespace declared. New VS recommends to declare it by a right click. I know Microsoft is supporting these features for developer's productivity. Unfortunately, it leads into lazy to learn.

Letz take a classic example of no standard library. On using /nostdlib switch, C# compiler wont refer MSCorLib.dll at all, meaning developer needs to share the list of all assembly references. In fact, Microsoft uses this switch when building the MSCorLib.dll assembly itself and in other cases. Sample compiler command layout would be:

csc.exe /out:Program.exe /t:winexe /nostdlib Program.cs

I know itz debatable question about productivity vs learning block; but itz a tech bit to think. At the same time, FW Expert like Brad Adrams gives better pictures on core libraries.

FrameWork Versions

Recently, one of my colleague got confused on installing two versions of VS and its related framework. It triggers the process to display the installed FW versions in a machine.

Each assembly you build can be either an executable application or a DLL containing a set of types for use by an executable application. Of course, the CLR is responsible for managing the execution of code contained within these assemblies. It means that the .NET Framework must be installed on the host machine.

Microsoft has created a redistribution package that you can freely ship to install the .NET Framework on your customers’ machines. Some versions of Windows ship with the .NET Framework already installed. You can tell if the .NET Framework has been installed by looking for the MSCorEE.dll file in the %SystemRoot%\System32 directory. The existence of this file tells you that the .NET Framework is installed. However, several versions of the .NET Framework can be installed on a single machine simultaneously.

If you want to determine exactly which versions of the .NET Framework are installed, you can test the subkeys under the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP The .NET Framework SDK includes a command-line utility called CLRVer.exe that shows all of the CLR versions installed on a machine. It can show which version of the CLR is being used by processes currently running on the machine by using the –all switch or passing the ID of the process you are interested in.

makefile in .NET

makefile is an interesting concept in UNIX world to read its instructions from text files. In current VS enviornment, developers jst click play button in IDE. No idea beyond that. But, VS has this makefile concept via 'Response File' with extension rsp.

A response file is a text file that contains a set of compiler command line switches. When you execute CSC.exe, the compiler opens response files and uses any switches that are specified in them as though the switches were passed to CSC.exe on the command line. You instruct the compiler to use a response file by specifying its name on the command line prepended by an @ sign. As an example, csc.exe @MyProject.rsp CodeFile1.cs CodeFile2.cs

This tells the C# compiler what to name the output file and what kind of target to create. As you can see, response files are very convenient because you don’t have to manually express the desired command-line arguments each time you want to compile your project. C# compiler supports multiple response files.

Compiler automatically looks for files called CSC.rsp. When you run CSC.exe, it looks in the current directory for a local CSC.rsp file—you should place any project-specific settings in this file. The compiler also looks in the directory containing the CSC.exe file for a global CSC.rsp file in %SystemRoot% folder \Microsoft.NET\Framework\vX.X.X directory (where X.X.X is version of installed .NET Framework). Settings in the local file override the global file.

When you use the /reference compiler switch to reference an assembly, you can specify a complete path to a particular file. However, if you do not specify a path, the compiler will search for the file in the following places (in the order listed):

1. Working directory.
2. Global file.
3. Any directories specified using the /lib compiler switch.
4. Any directories specified using the LIB environment variable

Itz possible for the compiler to ignore both local and global CSC.rsp files by specifying the /noconfig command-line switch

disassembler concern

Couple of weeks back, our dotnet manager Srini raised the disassembler concern against IP(Intellectual Property). Yes, it’s true. Three options to mitigate:

At first, in typical n-tier modern architecture, Core logic resides in server-side code (such as a Web service, Web form, or stored procedure) and so the assembly resides on your server. Because no one outside of your company can access the assembly, your IP is completely safe.

Second point is related to obfuscators. For distributing assemblies, you can obtain an obfuscator utility from a third-party vendor. These utilities scramble the names of all of the private symbols in your assembly’s metadata. It will be difficult for someone to unscramble the names and understand the purpose of each method.

On dissatisfaction of obfuscators, you can consider implementing your own sensitive algorithms in some unmanaged module that will contain native CPU instructions instead of IL and metadata. Then you can use the CLR’s interoperability features (assuming that you have ample permissions) to communicate between the managed and unmanaged portions of your application. This is third option.

Thanx for Srini's feedback to think in this line.