Hiro, the World’s Fastest IOC Container
Posted by gamlerhart in .NET, software-development on July 1st, 2009
The creator of the LinFu-library is working on the ‘world’s fastest IOC container’, called Hiro. Basically Hiro reads once the configuration and then it compiles everything to a fixed, immutable container. The compiled container has then ‘burned in’ the wiring of all components in IL-Code. So there’s no state, no map lookups and no locking required. This makes Hiro a whole magnitude faster than traditional IOC-Containers like AutoFac, Ninject etc.
Of course, due the container is compiled, it isn’t as flexible as a non-compiled container. But I think it will serve its purpose well. Most of the fancy features aren’t that important.
That said, I think most of the projects don’t really care about the speed of their IOC-container. The average application doesn’t create hundreds or thousands of service-instances per second. So for the average application there’s no need for a faster container. However I can image application which will benefit massively from a faster one.
So for my projects I’ll continue to use the wonderful AutoFac-container.
More info on Hire:
Project Natal
Posted by gamlerhart in microsoft on June 4th, 2009
Project Natal is the vision to interact with video-games without a controller. Cameras are used to captures movement, recognize people etc. Basically an EyeToy version 2.0. This is a very ambitious project for the XBox 360, but in my opinion its possible.
However there is this Milo-demo, where the game character recognizes emotions, remembers stuff and interacts very naturally. In my opinion this is clearly a nice demo, but won’t work in reality. Because having such a precise recognition is an extremely difficult task. But there’s also the AI part. An ‘game’-AI can feel quite natural at first sight. But it certainly fell unnatural as soon as you interact heavily with it.
Milo-Video:
Motion-Capture-Demo:
Via: www.irrlicht3d.org
Star-O-Meter
Posted by gamlerhart in 42 on June 3rd, 2009
I’ve finally introduced a star-rating-system for my little reviews =). Of course the rating represents my opionion and isn’t objective at all. So all reviews have a nice little ‘Star-O-Meter’. Together with my new useless ‘review-cartoons’ the posts are more visual. So you don’t need to read all the bla-bla \o/
I’ve updated nearly all review-posts with the shine stars. Furthermore I’ve added a cartoon to the Breaking Bad review.
Depoy a ClickOnce-App from a Build-Server
Posted by gamlerhart in .NET, microsoft, software-development, tools on May 19th, 2009
ClickOnce (Wikipedia, MSDN) is an easy way to deploy and update your .NET-application. Its also easy to set it up in Visual Studio and run it from there. It increments the version-number, compiles and deploys the application in one and simple step. But I really don’t want to publish software with my IDE on a developer-machine. Of course I want initiate the deployment from a build-server. While ClickOnce-deployment works nicely within Visual Studio, it can be a real bitch running stand-alone.
Visual-Studio uses MSBuild to build stuff, so the first step is obvious. The ‘publish’-target creates the ClickOnce-Installer etc. Go to your project, open the console and try it.
%windir%\Microsoft.Net\Framework\v3.5\msbuild.exe /target:Publish /property:Configuration=Release
However running the ‘publish’-target won’t update the version-number nor copy it to the target (documented here). This only works within Visual Studio. But this isn’t necessarily a bad thing, because now you have full control over it. The revision is set with the ApplicationRevision-property:
%windir%\Microsoft.Net\Framework\v3.5\msbuild.exe /target:Publish /property:Configuration=Release;ApplicationRevision=42
This way you can set this property with your build-server. So its possible to synchronize application-versions with build-runs or something else. The published files are in the “%Project%/Release/app.publish/”-Directory, ready to copy to the server. So the best way is to write a little MSBuild-script. In my example I invoke just the ordinary-build-target and copy then the files to a server. The ApplicationRevision-property is set externally by the build-server or command-line:
<?xml version=”1.0″ encoding=”utf-8″?>
<Project ToolsVersion=”3.5″ DefaultTargets=”Publish” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″>
<PropertyGroup>
<ProjectName>MyExampleProject</ProjectName>
<DefaultBuildProperties>MyExampleProject</DefaultBuildProperties>
<ProjectPublishLocation>.\bin\Release\app.publish</ProjectPublishLocation>
<ProjectClickOnceFolder>\\TargetServer\deployments</ProjectClickOnceFolder>
</PropertyGroup>
<Target Name=”Publish” DependsOnTargets=”Clean”>
<Message Text=”Publish-Build started for build no $(ApplicationRevision)” />
<MSBuild Projects=”./$(ProjectName).csproj”
Properties=”$(DefaultBuildProperties)”
Targets=”Publish”/>
<ItemGroup>
<SetupFiles Include=”$(ProjectPublishLocation)\*.*”/>
<UpdateFiles Include=”$(ProjectPublishLocation)\Application Files\**\*.*”/>
</ItemGroup>
<Copy
SourceFiles=”@(SetupFiles)”
DestinationFolder=”$(ProjectClickOnceFolder)\”/>
<Copy
SourceFiles=”@(UpdateFiles)”
DestinationFolder=”$(ProjectClickOnceFolder)\Application Files\%(RecursiveDir)”/>
</Target>
<Target Name=”Clean”>
<Message Text=”Clean project” />
<MSBuild Projects=”./$(ProjectName).csproj”
Properties=”$(DefaultBuildProperties)”
Targets=”Clean”/>
</Target>
</Project>
After running, testing and improving the deploy-process, try it out on your build-server. If it runs your lucky. But, your build will probably fail with a message like: “setup.bin” not found in “ExampleProject/Engine”.
Now things start to get ugly, really really ugly. You need the ‘bootstrapper’-files to build the click-once-setup. This files are located normally under ‘C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper’. (And installed by Visual Studio. But I really don’t want Visual Studio on my build-machine). So copy them to your build-machine. Then you add this registry-key:
Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\3.5
Value:
Name: Path
Type: REG_SZ
Data: c:\CopiedFiles\
Run the build-scrip again on the server. If it works now, well done. If it still fails with an error like this: “Signtool requires CAPICOM version 2.1.0.1” it gets even uglier!
Download the CAPICOM SDK here. Install/Extract it. There will be a ‘capicom.dll’ in it. You can copy it to the %windir%/system32. Then you need this register it. Run with administrator-privileges “REGSVR32 capicom.dll”. Finally your build should run. \o/
If you know a better way to run ClickOnce-deployment without Visual-Studio and without hacks, please tell me. Its really ugly at the moment.
Sources and references:
- ClickOnce: http://msdn.microsoft.com/en-us/library/t71a733d(VS.80).aspx
- MSBuild: http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx
- MSBuild and ClickOnce: http://msdn.microsoft.com/en-us/library/ms165431(VS.80).aspx
- Bootstrapper/setup.bin-registry-hack: http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7672078f-f2bd-4142-b8a9-740c2a8a5ae7
- CAPICOM-Hack:http://geekswithblogs.net/hinshelm/archive/2007/02/07/105684.aspx
Mocks for internal interfaces
Posted by gamlerhart in .NET, software-development on May 7th, 2009
Maybe you’ve already seen an exception like this:
Castle.DynamicProxy.Generators.GeneratorException: Type is not public, so a proxy cannot be generated. Type: SpielWiese.IReportSender
…stack-trace…
at SpielWiese.TestSomething.ExpectReportsSend() in Program.cs: line 64
What I’ve tried is to create a mock-object with Rhino-Mock. Since this interface is only intended for usage within the assembly it’s declared as internal interface. So Rhino-Mock fails and I really don’t want to create a mock manually. The quickest and dirtiest way would be to make the interface public. But I really don’t want to leak internal stuff just for tests.
So the second approach is to make the internals visible to Rhino-Mocks.
[assembly: InternalsVisibleTo("Rhino.Mocks")]
But it will fail as well. Since Rhino uses Castle-Proxies, I tried:
[assembly: InternalsVisibleTo("Castle.DynamicProxy")]
It still won’t work. The reason for this is simple. The Mock-Factory has to generate code. The generated code is hosted in a separate assembly. So you have to make the dynamic assembly visible to your code under test.
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
This is similar with other mock frameworks or proxy-frameworks.
Source: http://ayende.com/Wiki/Rhino+Mocks+-+Internal+Methods.ashx
Demo-Code: demo-code
Lang.NET Symposium 2009
Posted by gamlerhart in .NET, channel 9, software-development on May 2nd, 2009
The videos of the Lang.NET are online. Again wonderful geeky talks about programming-languages and other programming-related stuff: http://www.langnetsymposium.com/2009/talks.aspx
One of the best talks is again from Erik Meijer. He explains his LINQ-to-Events stuff with coins and his talk is really fun to watch. Sadly the video only includes the slides: Silverlight, WMV
Additionally there are some back-stage talks on channel9. Gilad Branchas Newspeak is most interesting. The concept with no global scope, objects as services etc. is fascinating. However it’s currently only in a experimental, partly in a conceptual state. And event if it will become usable in like 5 years, I don’t see it adopted by the masses.


(4.5/5)

(4/5)
