Changes to storage Emulator in azure sdk 2.3

I have always created my Azure Storage Emulator on my local SQL server instance via executing DSInit command line tool, but that has changed with the latest release of the SDK that came out last week (3rd April 2014).

image

Why? Well… Microsoft has decided to deprecate it, that simple. So if you find yourself in a similar situation I’ve just found myself, the new command that can save your life is “WAStorageEmulator.exe” that can be found in “C:\Program Files (x86)\Microsoft SDKs\Windows Azure\Storage Emulator”. There’s also something else that Microsoft has deprecated,  the UI for the storage emulator now all we have is a command line.

Regards,

Angel

.NET Native

I can still remember last year when I attended the MVP Summit 2013 an awesome talk by the Visual C++ team around “CLR team working closely with Visual C++ team to improve performance of .NET apps as well as making .NET available for every device”.  Unfortunately, I could not disclose that information because it was under NDA but Microsoft has made it public at /Build 2014 so I can freely blog about it now.

At the very beginning, I thought about going native not the conference though, but being able for .NET to emit native code which is compiled into C++ binaries (that was my assumption), and it makes me very happy to know that my assumption was spot on.

As many developers are aware (even the .NET dudes) C++ is an awesome, cross-platform and high performing language which can target any device, this is specially important these days when mobility and cloud have changed the computing paradigm. Managed languages are not as efficient as native, mainly because the consume more power, this is mainly related to all of the goodness they provide developers (memory allocation & de-allocation among others).

The creator of C++ Bjarne Stroustrup has a cool video on Youtube about “How C++ Combats global warming”

 

.NET Native is currently in developer preview, more resources and video below

 

 

Regards,

Angel

Checking whether the clr requires to be loaded with visual C++

As part of this personal project I am currently working on, I need to  reuse a C# component I wrote a few years back. I think I have blogged about this topic in the past on my old blog, but here I will show you how to check whether the CLR requires to be loaded beforehand, as well as a convenient way to “warm up” .NET code for execution.

////////////////////////////

// Check if CLR is loaded //

////////////////////////////

 

BOOL MyClass::CheckIfClrIsLoaded(const CComPtr<IEnumUnknown>& pEnumerator) {

    ULONG fetched = 0;

    DWORD bufferSize;

    auto retval = FALSE;

    wchar_t buffer[MAX_PATH];

    CComPtr<ICLRRuntimeInfo> pRuntimeInfo;

 

    while (SUCCEEDED(pEnumerator->Next(1, (IUnknown **)&pRuntimeInfo, &fetched)) && fetched > 0) {

        if ((SUCCEEDED(pRuntimeInfo->GetVersionString(buffer, &bufferSize))))

            if (wcscmp(buffer, L"v4.0.30319") == 0) {

                retval = TRUE;

                break;

            }

    }

 

    return retval;

}

 

///////////////////////////////////////////////////////////////////////

// Load, Initialize CLR and load dependant assemblies into AppDomain //

///////////////////////////////////////////////////////////////////////

 

void MyClass::InitializeClr() {

    CoInitialize(NULL);

 

    HANDLE hProcess;

    ExecuteArgs args;

    auto isLoaded = FALSE;

    CComPtr<ICLRMetaHost> pMetaHost;

    CComPtr<ICLRRuntimeInfo> pRuntimeInfo;

    CComPtr<ICLRRuntimeHost> pRuntimeHost;

    CComPtr<IEnumUnknown> pEnumerator;

 

    args.pwzAssemblyPath = L"MyAssembly.dll";

    args.pwzTypeName = L"MyAssembly.MyClass.BusinessRules";

    args.pwzMethodName = L"PreLoadData";

    args.pwzArgument = L"";

    args.pReturnValue = 0;

 

    if ((hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId())) != NULL) {

        if (SUCCEEDED(CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID*)&pMetaHost))) {

            isLoaded = SUCCEEDED(pMetaHost->EnumerateLoadedRuntimes(hProcess, &pEnumerator)) && CheckIfClrIsLoaded(pEnumerator);

            if (!isLoaded &&  SUCCEEDED(pMetaHost->GetRuntime(L"v4.0.30319", IID_ICLRRuntimeInfo, (LPVOID*)&pRuntimeInfo))) {

                if (SUCCEEDED(pRuntimeInfo->GetInterface(CLSID_CLRRuntimeHost, IID_ICLRRuntimeHost, (LPVOID*)&pRuntimeHost))) {

                    pRuntimeHost->Start();

                    pRuntimeHost->ExecuteInDefaultAppDomain(args.pwzAssemblyPath, args.pwzTypeName,

                        args.pwzMethodName, args.pwzArgument, &args.pReturnValue);

                }

            }

        }

    }

 

    CloseHandle(hProcess);

 

    CoUninitialize();

}

 

.NET provides a few interfaces that enable Visual C++ developer to host and use the CLR from native code applications. In order to improve performance and minimize the load time/first execution of .NET code it’s a good practice to load all of the dependencies (assemblies) required by the target library. As you can see I use smart pointers to do all of this because .NET is COM based and when it’s not done properly one can incur in memory leakage. It’s a good thing we got smart pointers Smile

Like I’ve previously mentioned, I needed to reuse an existing .NET assembly, well, it’s a bit of a shocker to find out the number of reference it loads even when I am not using them Disappointed smile

image

Extending a custom property page by overriding its Window Procedure

I am currently working on a personal project which requires to extend the operating system shell via a custom property page (IShellPropSheetExt interface), however, this customization has to behave differently to the default behaviour of the Shell, therefore I have to intercept the click event of any of the property page buttons (e.g.: Ok, Cancel or Apply). In order to do that, I must “override” the Wndproc of the original dialog and then run my custom code. This is shown in the code snippet below.

/// <summary>    Original WndProc. </summary>

WNDPROC pWndProc;

 

LRESULT CALLBACK CustomWndProc(HWND hwndDlg, UINT msg, WPARAM wParam, LPARAM lParam) {

    FindChild* findChildWnd;

    auto retval = CallWindowProc(pWndProc, hwndDlg, msg, wParam, lParam);

 

    switch (msg) {

    case WM_COMMAND:

        auto selectedButton = LOWORD(wParam);

        if (selectedButton == IDOK || selectedButton == IDAPPLY || selectedButton == IDCANCEL) {

            auto enumChildProc = [](HWND hwnd, LPARAM lParam)-> BOOL {

                auto retval = TRUE;

                wchar_t buffer[MAX_PATH];

                auto lParamValues(reinterpret_cast<FindChild*>(lParam));

 

                if (GetClassName(hwnd, buffer, wcslen(buffer)) > 0) {

                    wstring className(buffer);

                    if (className.find(lParamValues->windowName) != wstring::npos) {

                        lParamValues->nMatchCount++;

 

                        if (lParamValues->FoundTargetIndex()) {

                            lParamValues->hFound = hwnd;

                            retval = FALSE;

                        }

                    }

                }

                return retval;

            };

 

            EnumChildWindows(hwndDlg, enumChildProc, reinterpret_cast<LPARAM>((findChildWnd = new FindChild)));

 

            switch (selectedButton) {

            case IDOK:

                SendMessage(findChildWnd->hFound, WM_APP, IDOK, NULL);

                break;

            case IDAPPLY:

                SendMessage(findChildWnd->hFound, WM_APP, IDAPPLY, NULL);

                break;

            case IDCANCEL:

                SendMessage(findChildWnd->hFound, WM_APP, IDCANCEL, NULL);

                break;

            }

 

            delete findChildWnd;

        }

        break;

    }

 

    return retval;

}