When wirting a Service Fabric Service that uses the Remoting Transport layer, you sometimes need to update the default settings to allow for a greater message size or operation timeout.

According to the documentation, this is achieved by overriding the default settings in the Assembly manifest file that you find under Properties/AssemblyInfo.cs

1
2
3

using Microsoft.ServiceFabric.Services.Remoting.FabricTransport;
// Allow messages up to 100 MB, operation timeout to 10m
[assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = 100000000, OperationTimeoutInSeconds = 6000)]

However, you might notice that if you created an ASPNET Core service (to use as a gateway perhaps), the new project type does not have the AssemblyInfo.cs file anymore. Even more, if you create it yourself, it will be ignored.

This is happening because in the new ASPNET CORE project type, the AssemblyInfo file is auto-generated during build. Since there’s no other way (as far as I could find) to update our remoting settings, we need to get rid of the auto-generated file and write our own.

First, create your own AssemblyInfo.cs file under the Properties folder.
Next, find the auto-generated file in the obj folder. Copy its contents over into your newly created file.
Lastly, we need to instruct the build system to not generate the file automatically any more.
We do this by updating the project file:

1
2
3

<PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

That’s it, with these changes, you now have the new remoting settings available for your ASPNET CORE project.

When working with CosmosDB GraphAPI it helps to understand how the engine stores or manipulates the inputs, so I will try to explain the data formats.

Read More

One of the best things about CosomosDB is the ability to mix and match APIs and models based on what makes sense for your use case.

Sometimes it just makes sense that your database is built as a graph, and in that case you can use the (familiar) Gremlin language to write your queries. However, for some things it might be easier or more optimal to use familiar DocDB APIs.

Read More

One of the interesting things that caught my eye in the newly released 0.3.0-preview SDK was the .limit() step optimization.
Like we saw in one of my older posts, limit() was executed client side, so you’d get the entire result set from the server and the client side sdk would filter and return it back to caller.

Read More

After fiddling with the requests for inserting data using Gremlin, I decided to check on some other common calls and I was not super impressed with the results.

Read More

Like we saw before, you can use the DocDB API or Gremlin interchangeably for inserting data, and you can also do the same for reads. Complex queries or traversals will still need Gremlin, but for simple reads you could (and probably should) use the DocDB API - and by simple reads, I mean reads where you know the ParititonKey and the Id of the node you need to retrieve.

Read More

Imagine a database system…
… where you don’t need to define a schema ahead of time. Which means you don’t need to worry about schema migrations or syncing your data models.

Imagine a database system…
… that is globally available by design and you can enable it in a matter of minutes with a few clicks.

Imagine a database system…
… that is elastically scalable by design and in near real-time. You pay for what you need, when you need it without spinning VMs up and down.

Imagine a database system…
… that is fully managed, on the best cloud out there, so you don’t ever need to worry about infrastructure and everything that comes with managing that infrastructure

Imagine a database system…
… that supports multiple data models (relational, table, graph, document) so you don’t ever have to compromise on one type, or have to use multiple databases for your needs.

Imagine a database system…
… that supports multiple APIs for manipulating your data. You can choose from a number of Apis like the familiar SQL, DocumentDB or MongoDB, Gremlin, Table API or even Cassandra.

Imagine a database system…
… that has 5 consistency levels that are easy to understand and define. Break away from just Eventual or Strong consistency of the other distributed database offerings out there.

Imagine a database system…
… that has single digit millisecond latency performance and availability guarantees backed by an SLA at the 99 percentile

If you got excited imagining… imagine no more, CosmosDB is here and it’s everything you’ve ever wanted from a database! Check it out today!

I was working on an ARM template the other day for deploying an ElasticSearch cluster on Azure. One of the things I needed to decide on was the SKUs of the VMs in the cluster. I knew I wanted a Linux machine but I wasn’t familiar with the SKU Names that I had to enter.

Read More

Part 1 - Introduction

Timeless values and principles

• Empower people
• Inclusive design
• Build trust in technology

Microsoft mission

Empower every person and every organization on the planet to achieve more.

The Numbers

500 MM Windows 10 devices
100 MM O365
140 MM Cortana users

Read More

Calling all Xamarin developers and enthusiasts. Microsoft and Xamarin is organizing a Xamarin developer event here in Toronto. Members of the Xamarin team form San Francisco are in town and will be delivering presentations and end-to-end mobile devops with Xamarin Mobile Lifecycle Solution

If you’re at all involved with Mobile app development with Xamarin you should definitely try to make it as I’m sure this will be a jam-packed information event.

You will likely find me in the attendance if you want to chat. Below you can find the event details and registration options.

Date: Thursday 13th April 2017
Time: 10:00AM to 1:00PM (EST)
Event Location: Microsoft Toronto Office, Suite 1201, 222 Bay Street, Toronto, ON, M5K 1E7
Registration: Spaces are limited, so please email Catherine Kerr with your name and contact details at your earliest

See you there!