Introducting my latest side project: FMData

Wednesday, September 5, 2018 by Nate Bross

I switched jobs in March of this year, that is a story for a different time, but the important thing is that it reintegrated me with some technology I had not used in quite some time: FileMaker. FileMaker is a database system that provides UI and basic scripting capabilities all in a single package. Users use the FileMaker client to access data stored in FileMaker databases, utilizing layouts and scripts in the database. Its an all in one system.

As a web developer with a lot of C# code under my belt, I wanted to connect to data in FileMaker from the outside. Historically the way to do this was through their XML Publishing Engine, I picked up an existing open source project and modified it to suit my needs. Ten years ago, this was a great solution and it worked well. It still does, but as things change so must we. In FileMaker 17 the Data API was introduced. It uses JSON and is RESTful. A new package was needed. Enter my side project: FMData. I built this as a learning exercise, but quickly realized it could be useful to other developers.

The library provides coverage for the FileMaker 17 Data API, and I've just released v2.1, cleaning up a handful of bugs and improving coverage of the underlying FileMaker API. I still don't have full coverage, but I'm inching towards it. I have tons of ideas for features and enhancements, so be sure to keep an eye on the project. If you find it useful let me know. If you find a bug, open an issue. If you have a feature idea, open an issue on github and consider making a pull request.

The package is available on Nuget, and getting some data is really this simple:

var client = new FileMakerRestClient("server", "fileName", "user", "pass"); // without .fmp12
var toFind = new Model { Name = "someName" };
var results = await client.FindAsync(toFind);
// results = IEnumerable<Model> matching with Name field matching "someName" as a FileMaker Findrequest.

That's all there is to it, and there's more examples on the project site:

Continuous Integration for Open Source Projects .NET Projects

Thursday, May 3, 2018 by Nate Bross

I operate a couple niche open source projects. They don't generate much activity, but they've been useful to me over the years so I share them with the world to help anyone else that happens upon them. 

They're hosted on my GitHub page. Which is great for sharing the source code and allowing folks to submit issues and submit pull requests (not that my projects are big enough to get any real activity, but I can hope). There isn't a good way to share the binary output from GitHub. You need to utilize additional tools and software. I'm using AppVeyor and MyGet and I outline my configuration below.

The full CI setup could be achieved with MyGet alone since they also offer build services; but I'm using a combination of MyGet (pre-release package hosting and AppVeyor for builds).

AppVeyor Setup

In order to get my .NET Standard 2.0 library to build in AppVeyor I had to make a few changes from the default configuration. 

Build Setup

build configuration: build nuget packages, do dotnet restore pre build

On the build configuration tab you need to tick the box to build Nuget Packages, and most importantly add a pre-build script to perform

dotnet restore

Deployment Setup

Deployment tab on the left as part of the build, not part of the AppVeyor project across the top.

On the Settings >> Deployment tab, in order to push to MyGet you will need to provide the MyGet Feed Url and API key. Both of these are easy to obtain on your feeds detail page. 


There are plenty of resources for setting up a MyGet feed, so I'm not going into those details, but this is where you get the settings utilized in AppVeyor:

myget nuget push url

The last step is pushing the MyGet packages up to Nuget; which can be done directly through the MyGet interface. Right now, this is a manual process for me. I have two separate AppVeyor builds setup for the same project, pushing to the same MyGet feed. One connected to the develop branch and one linked to master. Within AppVeyor I have enabled assembly version patching so they all end up in the MyGet feed and I can push the master releases out to Nuget.

I'm looking into having the build create release tags in the repository after a successful build, but haven't figured out how I want that to work yet.


Fix for Remote Desktop Connection Manager (RDCMan) on High DPI Devices

Tuesday, November 28, 2017 by Nate Bross

If you're like me, you probably find yourself needing to remote into servers from time to time. Again, if you're like me, you probably got tired of doing it manually and found a tool to help you. I know did, I found and live by RDCMan.

One of the many beautiful features, is it gives you the ability to store an encrypted file with all your connection, display, settings along with credentials. So you're only a short double click away from being on the remote desktop you need to be on.

Its been working for me for years. In the last few years, High-DPI devices have become more common and RDCMan didn't play well. That is, by default. One simple operating system setting/configuration was all it took to get sorted out. 

Simply go to the properties of your shortcut, on the compatibility tab, change the HighDPI drop down from Application to System.


I'm rather disappointed it took me this long to figure out, but now that I have it working its fantastic and my remote sessions are no longer scaled way down to fit.

Dream Build Play: Part One - My Technology Stack

Monday, October 23, 2017 by Nate Bross

Choosing the right technologies for a project is one of the early decisions you must make and its a crucial factor in long term success. Technology choices can make a project go smoothly or they can be a constant impediment to forward progress.

Since this a just for fun build, I'm going to try to throw a bunch of things at it, but first lets start with the basic technology stack.

Front end:

UWP, obviously, but more specifically the plan is to use html and javascript as the building blocks packaged up inside a UWP application. To cap things off, I figured why stop there, lets throw in typescript, to get statically typed javascript and throw in a couple front-end frameworks to boot. Aurelia, for data binding and non-gamey stuff. Phaser-CE for gamey things. 

Server Side:

I'm a Full Stack .NET developer in my day life, so in order to focus on the game specifics for the front end, I decided not to bite off another layer of complexity by choosing a tech stack I'm not already proficient with. With that in mind, C# service/controller layer and Razor views (that serve up the baseline for the aforementioned Aurelia framework to pickup). The plan is to host this on Azure App Services, and then to throw some new things in the mix, I'm going to try to find a way to fold in CosmosDB, Notifications Hub, and maybe even some container services. 

To summarize this up into a nicely packaged list:

  • Languages and Frameworks
    • C# + ASP.NET Core
    • Typescript + Aurelia
    • Phaser-CE
  • Apps and Tools
    • Tiled
    • Paint.NET 
    • The GIMP

The idea is by using a lot of tooling I'm already familiar and comfortable with, I'll be able to focus on the game specific tasks for this project. 

A fix for the error: A route named 'something or other' is already in the route collection. Route names must be unique.

Friday, October 6, 2017 by Nate Bross

I was setting up a new Umbraco Project, for the first time in a while. At my company, we have a base implementation that we 'fork' manually by copy/pasting the repository and creating a specific one for each client. 

I set it up and try to run it, and immediately hit this error:

A route named 'something or other' is already in the route collection. Route names must be unique.

A good error message that describes the problem exactly, and how to fix it. My problem? I'm not defining any routes manually, and this is the same code that was working in another project. What gives? There are lots of posts explaining how to update your RouteConfig to remove the duplicate. 

Eventually I come across a highly up voted post, suggesting to delete the bin files and try again. I know the bin folder is created by the compiler for my project; but deleting everything in there felt a little draconian to me. This is an axe kind of fix, and I'm thinking this is more of a scalpel problem.

One of those manual steps to creating our client specific projects, is to go in and rename folders, solution, and project files (and their internal path references to each other). This went just fine, and from a Visual Studio perspective everything linked up worked, and built. 

Then it hit me. I renamed the project and its compiled output was in the bin folder along with the newly built and compiled version with my new name. Ultimately I had two copies of identical code in the bin folder with different physical file names.

I deleted the dll files from my original build with the old name, and that ultimately fixed the problem. 

 View More Posts