I’m working through a support issue with Microsoft to do with Azure Service Bus. One potential issue raised was that my application is running as 32bit rather than 64bit. When I checked it out, the Prefer 32 bit setting was enabled on the project. This means that the exe’s will be running as x86 even though it is running on an x64 machine.
All the way back in 2009 I wrote a little console application that assisted with renaming a Visual Studio project and/or namespace. It was handy in that it took into consideration the solution being under source control with TFS. Over the years I have been using TF source control less and Git more. On the odd occasion I have also used this script for solutions that are not bound in source control.
I have refactored the script to take out the TF integration, remove the logging that was just causing a whole lot of white noise and to add in a few more out of the box exclusions for directories to skip in the process.
I’ve started converting projects from TFSC to Git in VSO. As part of this process I am working out the best way to achieve semantic versioning. GitVersion looks like a great product to assist in this. By default however the version numbers that it produces are not supported by NuGet.
The particular problem with NuGet version numbers can be read in more detail here.
The previous two posts (here and here) have looked at a POC for returning dynamic data from Web API and then adding a defined schema to a semi-dynamic object. This post is the next POC that looks at how to POST that data to the Web API.
The design goals are similar to the previous POCs. There is a type that has some known properties and then contains JSON serialized metadata for all the remaining dynamic properties. The storage and retrieval of the metadata should conform to some known schema for that metadata.
The code here uses JObject from Newtonsoft.JSON as the mechanism of making the dynamic data available to the controller action. We then need to separate out the known properties from the metadata properties and convert all of them to the correct type.
Following on from the previous post, I want to prove that I can define a schema for metadata and have that metadata returned with core type information in a Web API.
For this POC, I will define the core type (DataEntry) and then dynamic metadata (JSON encoded data). I want the Web API to correctly handle the type information for this metadata and return the correct wire formatting.
This POC uses DynamicObject to be the bridge between the DataType, its metadata and its metadata schema. It provides the type information for Web API so that it can be correctly returned over the wire.
I am looking at the possibility of using dynamic types in a Web API for my current client. They have a need to return data that mostly has the same structure. I want to run a few POCs to see if this is possible.
Rather than store each data type in it’s own data structure (such as a database table), storing core type information and then dynamic fields would be a very flexible outcome. Is it something that Web API will support though?
The first POC is to determine whether Web API will render dynamic types of differing structures. At the same time, can this be done with a Task based API. Here is the first test.
I’ve been running this blog on the Microsoft stack since way back in August 2001 with almost 900 posts. I think that might have even been before blogging was called blogging. My viewpoint on blog engines has changed substantially over the years to the point where the bells and whistles of the ‘modern’ blog engines are not as attractive as they once were.
I’ve now converted the blog over to Jekyll using GitHub pages to make my blogging life a lot easier. As part of this process, I have removed a whole lot of old posts and files that are no longer relevant to the current state of technology. This blog now has half the posts it once was and is much more technology focused.
I’ve been converting my code over to RequireJS and have been battling how to get this to work with the ReSharper test running which uses Jasmine. The main issue is that Jasmine runs the page on load of the browser document (the spec runner) before RequireJS has loaded dependencies. The reason for this is that RequireJS loads dependencies asynchronously. By the time they have loaded, the test run has already completed.
The primary issue here however is that scripts will still use the console but the script might not execute in a browser the supports it. This script might be something that you control, but could also be a third party script you import. In either case, there are two things that should happen here. Firstly and most importantly, the script shouldn’t fail because the browser doesn’t support console logging. Secondly, the console functionality should do its best attempt at getting console logging to work when at all possible.
The two go-to packages I use for unit testing are NSubstitute and FluentAssertions. NSubstitute is a wonderful package that solves all the pain points I had testing with RhinoMocks. Similarly, FluentAssertions is an awesome package for running assertions on data with very powerful evaluations. A great feature of both these packages is the really good feedback about failures. There is one scenario however that falls in the cracks of between the functionality of these two packages.
NSubstitute is really good at setting up stub behaviour using predicate or value argument matching and asserting received calls with the same argument matching. FluentAssertions is really good at asserting whether values satisfy specified criteria. The difference between these packages is that NSubstitute works with predicate expressions whereas FluentAssertions evaluates assertions and throws an exception if the assertions fail.
The gap in functionality here is where I want to use NSubstitute to evaluate received calls but the power of FluentAssertions evaluation in the argument matching. This doesn’t work because NSubstitute uses Arg.Is<T> (Expression<predicate<T>>) whereas FluentAssertions will throw an exception. We need the ability to bridge these two packages so that we can have the power of FluentAssertions executing within an NSubstitute argument matcher and allowing the test code to remain readable.