Lately I have been working on an Azure project for a client (if you haven’t noticed from my Azure-centric blog posts as of late). A part of this, we have built a WCF service that exposes the functionality that we need. However, we are not actually building a client, only the service. So we don’t have a great way of testing the service. This is obviously where the “WCF Test Client” comes in.
For those of you who don’t know what this is, it is a small client that hooks up to any available service and creates a proxy for you. You can then use this proxy through the interface and call your service.
More...
As I was working with some of my demo code for the Azure posts I have been putting up lately, I came across a very odd thing. I had a solution with several projects that built and worked perfectly fine. I did however need to make some changes to the solution before zipping it up and putting it on my blog. So I made a copy of the solution folder, removed my source control bindings and everything else that shouldn’t be in the zip.
Before zipping it up, I thought I would just make sure it built ok after my changes, which it obviously should as I made no code changes. So I loaded the solution into Visual Studio and everything looked fine. But pressing Ctrl+Shift+B made Visual Studio cough and tell me that XXX was not available in namespace YYY, which is really odd as I had made no code changes.
More...
15. September 2011
ZeroKoll
BUILD , Windows 8
Windows 8 introduces a new concept called “charms”. Charms are basically a set of features that is handled by the OS, but is used/implemented/extended by the installed apps.
That sounds really confusing…but it isn’t…or…well…I will try to explain…
When you expand the “toolbar” on the right hand side of Windows 8 (swiping from the right edge of the screen towards the center) you are faced with a couple of buttons. First off the start button (Windows logo), but also share, settings, search. These are all “charms”. A charm is basically a feature that can be called up through the OS by using that toolbar, but should be implemented by the individual apps.
More...
Ok, so I will only quickly mention this as I find it awesomely cool, but have limited information. But basically, all apps get the ability to store settings and a certain amount of data in a roaming data store. This roaming data store is then synched “up” to Live services, and then down to all the users devices. This way, all settings and app things that makes sense to have identical in all places will just be on all devices automatically.
This means that a setting only needs to be done once, and then all your devices will have the same setting. I do however assume that you can manipulate what settings are synched, but I have to check…
More...
One “feature” in VS2010 (and 2008 I assume) that bugs the hell out of me, is the way that referenced assemblies are packaged in Silverlight projects… And please let me know if you know of any fix for this!
Imagine that you have a solution with at least 2 projects. One Silverlight application project, and one class library project. The app project references the class library project as it contains functionality it needs. The class library project in turn references another assembly (or maybe more than one) that is needed for it to be able to run. This (or these) other assemblies are not default Silverlight assemblies, so they will not be on the target machine and needs to be included in the deployment… Unfortunately, this is where VS screws up…
More...