מצורפים המצגת והדוגמאות שנתתי הבוקר בבית הפתוח של Microsoft בבית חיל האויר.

• Read more
• No comments

זמין להורדה גירסה 4 בטא של המוצר ReSharper (www.jetbrains.com) שהוא Addin  חכם ל-Visual Studio 2005 ו-2008 ומטפל בשפות C# ו-VB. גרסה זו תומכת ב-C# 3.0 ו-VB 9.0.אחד המאפיינים הנחמדים שלו היא היכולת להמיר משפט LINQ  בפורמט שאילתה לגרסת extension methods . לדוגמא, את השאילתה הבאה

var products = from p in ctx.Products

              where p.Category.CategoryName.StartsWith("B")

              orderby p.UnitPrice descending

              select p;

הופך בלחיצת כפתור ל-

var products = ctx.Products.Where(p => p.Category.CategoryName.StartsWith("B")).OrderByDescending(p => p.UnitPrice);

נחמד מאד! באג אחד שנתקלתי בו (לפחות על המערכת שלי) היא הנטייה של ה-addin לרסק את VS2008  אם יש פרויקט WebSite  ב-Solution.

• Read more
• No comments

I was recently asked how a managed application can know the actual size of managed objects it allocates. Although there exists a Marshal.SizeOf method that seemingly can do the trick, this only works for value types, as the method is intended to be used in interop scenarios where some unmanaged memory must be allocated in managed code and passed to some unmanaged function. This question, and others like it can best be answered by using a the .NET profiling API.

The .NET profiling API allows the (native C++) programmer to inject a DLL that can receive various events from the CLR during execution of a managed application. A .NET profiler does not only enable to "profile" an application, but also allows the code to interrogate the CLR for various pieces of information, such as object size. Interesting events might be loading of an assmbly, starting/ending of a GC cycle, creation/destruction of AppDomain, and many others.

To write such a profiler, one must use the .NET profiling API. What this means is writing a COM class that implements the ICorProfilerCallback2 interface, and meaningfully implementing the required methods for the interesting notifications. During the implementation of the Initialize method, the profiler code receives a pointer to the ICorProfilerInfo2 interface implemented by the CLR. The profiler should cache it and use in the notifications implementation to extract more info from the CLR.

Also, in the Initialize method, the code calls the CLR's SetEventMask method to indicate which events it wants to be notified. This is an optimization, so the CLR is not bothered with calling the profiler on every event, but only on the requested events.

To install the profiler, the COM dll should be registered as all COM DLLs, using regsvr32.exe (assuming, of course the DllRegisterServer function is in there. If you use the ATL library to write the COM DLL, then this is implemented for you).

Then, 2 environment variables must be set: COR_ENABLE_PROFILING=1 and COR_PROFILER=<progid or clsid of COM class>. For example, the settings needed for tha attached sample profiler are:

set COR_ENABLE_PROFILING=1

set COR_PROFILER=SampleProfiler.Profiler

The scope of setting of these variables matters. If they are set in a dedicated command prompt, all .NET apps starting from that command prompt will be profiled.

If they are set in user scope, then all .NET apps running from that user's account are "profiled", i.e. the DLL gets injected into the process. If the vars are set in system scope, all .NET apps are profiled.

The profiler should transmit in some way the info it gathers to some repository or other listening app that can show the info in a meaningful way.

I've attached a sample profiler that writes its info to a file to the c:\temp folder (so make sure this exists) as a simple log file just for demo purposes. It captures the timings of events such as start/end of GC, AppDomain creation/destruction and assembly loading. The coed is written with VS 2008 but can be written with any VS verstion. It uses ATL to create the required boilerplate COM code and just implements the necessary interface.

• Read more
• 2 comment(s)

C++/CLI allows relatively easy wrapping of unmanaged elements into usable types from the managed world. In the unmanaged world, I've been using for years the notion of shared memory - the ability to share block of memory between OS processes in an easy way. I've not seen this exact functionality anywhere in the .NET framework, so I decided to implement a simple mechanism around the file mapping concept (as it's referred in the SDK docs); and besides, it's a nice enough thing to try with C++/CLI.

The native functions in question are CreateFileMapping, MapViewOfFile and friends. Quite easy to use natively, I've created a managed type called SharedMemory that encapsulates their use. An internal CriticalHandleZeroOrMinusOneIsInavlid-derived type encapsulates the resulting handle. Another internal type, SharedMemoryStream is responsible for abstracting the access to the memory block with a normal System.IO.Stream.

I've simplified the implementation by always creating a read/write block (the native API allows read only as well).

To actually share memory blocks, the same name (a simple string) must be supplied in the constructor. This will make sure the same kernel section object is accessed underneath.

The download includes two projects. The SharedLib project contains the C++/CLI implementation (all Visual Studio 2008). The second contains a simple Windows Forms test app. To try it, run 2 instances of the test app. In one instance, enter some text in the textbox and click Write. In the other instance, click Read. You should see the stored text. Of course, the data can be anything - anything you can put in a Stream.

Enjoy!

• Read more
• 2 comment(s)

טק-אד נגמר... פסח נגמר... חוזרים לשגרה - הרצאות, טכנולוגיות, קורסים...

ב-28 למאי אני מעביר "בית פתוח" במייקרוסופט (זה יהיה בבית חיל האויר) בנושא C# 3.0 ו-LINQ. כל מי שעדיין לא יצא לו להכיר את החידושים המגיעים עם Visual Studio 2008 וה-.NET 3.5, מוזמן. לינק לרישום ניתן למצוא כאן.

• Read more
• No comments