My Life and Code

I ran into another fun problem today (why do so many of my blog posts contain that phrase?): I'm working on an ASP.NET 5 (MVC 6 / DNX) application, and I'd created a class that derived from another class. For example: (pseudo-code) public class Element public class HeaderElement : Element There's also a class which contains a generic list of the parent type: (pseudo-code) public class Section  { ... (other stuff) ...    public List Elements { get; set; } } Nothing unusual here, right? Well, I was sending that Section class shown above to client-side calls in JSON format, and everything was fine. However, when POSTing or PUTing back to my server-side controller, all instances of that derived HeaderElement class were instead deserialized as instances of plain old Element (the base class). It looked like I was going to have to write my own custom model binder for this... ...or so I thought. Turns out, there was a much simpler solution: setting the TypeNam

I've been encountering a fun bug in an ASP.NET 5 project in Visual Studio 2015. From time to time, I get messages like the following when trying to compile the app: The type or namespace name 'AspNet' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) The fix for this is to simply remove one of the references from your project.json file, save the file, then re-add the reference and save the file again. All of that removing and re-adding causes the packages to get updated. A weird problem, but thankfully, a simple fix until a real one is implemented.

I recently encountered an issue when writing a unit test for an Angular controller which was using the $inject property to specify its dependencies: even though I was using Jasmine to create mocks of the dependencies, the $inject property was overriding those and using the $provide service to instantiate new instances of the objects based on name. I went about setting up a beforeEach() call in the test spec to associate my mocks with the $provide service. However, I couldn't set up one of the mocks beforehand because it returns promises and I therefore needed to make use of the $q service to set up the mock. I tried to add an empty {} object to the $provide service, but this didn't work (I received different errors in the various stages of my work on this, from errors about a function being undefined, to one about there not being a constructor). What I had was a "chicken or the egg" situation: the $provide service registers providers for the $inject service to use,

Recently I've been working on a web application using ASP.NET 5 and today had to deploy it to a web server in our test environment. Here are the steps I took to get this to work: Published the website project in Visual Studio 2015 by right-clicking on the project and selecting "Publish", I used the file system publish option, and specified the 64-bit version of the runtime we're using (in this case, 1.0.0-beta5). This is important, as I was unable to get IIS to host this website using the x86 version. I specified a path outside of the solution directory for the publish output. Inside the publish directory, the publish process created 2 folders -- approot and wwwroot, as well as a file called web (no extension), and web.cmd. On the web server, I created a new folder for the website. Inside this folder, I placed the output from the publish (the approot and wwroot folders and the two web files). I created a new website in IIS on the web server. For the app pool, I se