VMware vSphere Web Services SDK – WDSL issues building the DLLs

stripeyfish

As per the developer setup guide for VMware vSphere Web Services SDK 5.0, you have to build your own DLLs from the wsdl files provided.
There are a few changes from SDK 4.0, most notably the lack of the genvimstubs.cmd and OptimiseWsStubs.exe files. However it is still fairly straightforward… apart from the initial wsdl command! read on…

Depending on where you extract the SDK zip file to you may end up with spaces in your path. After lots of head scratching it turns out wsdl.exe does not like this! If you have spaces in your path, then when running command “wsdl.exe /n:VimyyApi vim.wsdl vimService.wsdl” you will get an error as follows – despite trying all combinations of environment variables, running from Visual Studio command prompt in the actual vim25 directory:
Error: Could not find a part of the path ‘c:program%20filesmicrosoft%20visual%20studio%209.0sdkvsphere5vsphere-wswsdlvim25query-messagetypes.xsd’.

So rather than copy to e.g. Visual Studio/SDK path…

View original post 95 more words

The .NET CoreCLR is now open source!

Again, I’m late to the party but here you go: https://github.com/dotnet/coreclr

__DynamicallyInvokableAttribute

It is undocumented, but it looks like one of the optimizations in .NET 4.5. It appears to be used to prime the reflection type info cache, making subsequent reflection code on common framework types run faster. There’s a comment about it in the Reference Source for System.Reflection.Assembly.cs, RuntimeAssembly.Flags property:

// Each blessed API will be annotated with a "__DynamicallyInvokableAttribute".
// This "__DynamicallyInvokableAttribute" is a type defined in its own assembly.
// So the ctor is always a MethodDef and the type a TypeDef.
// We cache this ctor MethodDef token for faster custom attribute lookup.
// If this attribute type doesn't exist in the assembly, it means the assembly
// doesn't contain any blessed APIs.
Type invocableAttribute = GetType("__DynamicallyInvokableAttribute", false); 
if (invocableAttribute != null) 
{ 
    Contract.Assert(((MetadataToken)invocableAttribute.MetadataToken).IsTypeDef); 
    ConstructorInfo ctor = invocableAttribute.GetConstructor(Type.EmptyTypes); 
    Contract.Assert(ctor != null); 
    int token = ctor.MetadataToken;
    Contract.Assert(((MetadataToken)token).IsMethodDef); 
    flags |= (ASSEMBLY_FLAGS)token & ASSEMBLY_FLAGS.ASSEMBLY_FLAGS_TOKEN_MASK; 
}

So here is where I landed…

For more details check out http://www.virtualclarity.com

This sort of code makes me very angy!

Tell me what’s wrong with this simple piece of code:

public class MyService : IMyService, IDisposable 
{
    private readonly IOtherService _otherService;
    public MyService(IOtherService otherService)
    {
        _otherService = otherService;
    }

    public void Dispose()
    {
       _otherService.Dispose();
    }
}

The answer is very simple: “I created you and I will be your end”, yet MyService didn’t create IOtherService, thus it has not right to call Dispose() on the service.”

Yet, at Mizuho, I saw many developers lacking this simple, yet critical design concept!

</rant>

Transferring the blog to dedicated hosting

Expect interruptions 😦