Archive | Uncategorized RSS feed for this section

WebApi 2.2 OData v4.0: When inexperience and academics impede real-world progress. What a shame!

23 Jul

So you’re excited about the release of WebAPI for the OData v4.0 protocol? You can’t wait to use the new features that will now allow you to code more efficiently and throw out your hacks from v3? We were glad to finally get rid of the $format “hack” along with tons of routing code that v4 can now handle more efficiently for us. Not to mention the relative ease of working with the oDataController in WA22OD4.

Alright, now we are ready to analyze our options as we prepare to move forward with a massive platform API to serve our SaaS clientele with mobile and developer OData access, widgets, remoting services and much more. And from what we can gather, WA22OD4 sure seems to offer us a rapid pathway to our end game. We were about ready to rumble, but in the spirit of always trying to go with the latest and greatest, I decided that we should try OData v4 before launching the API platform.

Went through the checklist:

  1. Updated from WebStack? 
  2. Fixed breaking changes
  3. Commented out old hack code? 
  4. Changed Controllers to oDataController and modified for correct functionality? 
  5. Feeling relieved by how smooth things are going? 
  6. Sit back, press the proverbial TEST button (Fiddler) and watch how life has just gotten better?   Uh…Oh!

The type ‘System.DateTime’ of property ‘Date’ in the ‘CompanyAPI.Models.AuthorizationResponse’ type is not a supported type. Change to use ‘System.DateTimeOffset’

What the heck is this?  Since when is DateTime not supported in ANYTHING?

At that moment, a scary thought runs through my head. Did the datatype standards change for datetime years ago and I’m the last person on the planet to find out? Of course, it has been known for some time that DateTimeOffset was to become the norm, but to just stop supporting DateTime so abruptly? This is a scary thought because with over 600 tables in our various databases and millions of lines of code that make up our platform (some legacy), I can’t even begin to imagine what it will take to start down such a conversion path. After all, we are about to launch our API. Nope, maybe in the near future, but for now we don’t have time for such an endeavor.

So I began my investigation into what must obviously had been a misunderstanding on my part. Then, to my utter amazement, I ran across this work item on codeplex. With the shocking title of OData V4 service should not support DateTime.

Wha.. Wha.. WHAT?

In reading further I notice that some clients in various scenarios were having issues with DateTime typed values and metadata. That’s a bummer. I guess if I run into those issues, then I’ll have to work for my money and find a way around it.

Now, you would think that the team would come up with workarounds or even announce deprecation of DateTime in models for future OData releases.

Well, you would be wrong. One simple, non-chalant sentence in the youthful team member’s work item post said it all:

‘We should generate a proper error message when DateTime is used in the model.’

Wait! Did he really just say that? Is that from this team or committee’s “decades” of experience?<si> Or maybe their academic adherence to all things, well, academic? Granted, a warning or even a deprecation into eventual obsolescence, maybe. Or even introduce methods for conversion on the wire. But to flat out throw an exception with DateTime in such widespread use around the globe? Preposterous! It was being buggy so just throw out support for one of the most commonly used datatypes?

And NO, I don’t want to go hacking around in the POCOsphere or change the generated entity classes as I use the Update model feature frequently and don’t want to deal with versioning my changes every time. I also don’t want to add a myriad of code that will hang around and potentially be overlooked when a more suitable solution presents itself.

So what is it with the DateTimeOffset?

I won’t get into specifics and bore you, but there is a preference to use the DateTimeOffset so that the value will be a specific set point in time, not a relative time like with DateTime (especially of DateTimeKind.Unspecified). Ok, that makes sense. But our platform operates in a manner which DateTime does the job. Maybe sometime in the near future we will look at changing to DateTimeOffset as it would be more beneficial for a variety of reasons. But for now, DateTime is in widespread use throughout, as is the case with the majority of .NET platforms worldwide.

With that said,

I know that most, if not all of those involved in this decision, both with MS and OASIS, are bright individuals that are just driving 100 miles a minute to get something where they envision it to be or feel strongly in their pursuit of strict adherence to standards. As an innovator and fellow problem solver, I can appreciate their desire to not let little things get in the way of the big picture. But with age and experience comes the wisdom and understanding that some of those little things can cause huge ramifications if not handled with proper care, consideration and planning.

What can you and I do about it?

Make them see the error of their ways!

Vote up!

Work Item: OData V4 service should support DateTime

You can view the OASIS committee proposal here: https://issues.oasis-open.org/browse/ODATA-220

Zeta Resource Editor 2.2.0.28 Excel Export fix

19 Jun

June 25 Edit: My fix below has now been forked at GitHub – Zeta Resource Editor. You can simply download the latest stable release from there.


 

Download as .key, then rename to .zip

As many have discovered, the ZRE (version 2.2.0.28) will not export to Excel due to a bug with Long to Int conversion. The developer doesn’t seem to be supporting it any longer, so I grabbed the source and fixed a simple typing issue then recompiled just the ZetaResourceEditor.RuntimeBusinessLogic.dll

  1. Simply download the ZRERuntimeBusinessLogic.key from this post and rename the extension to .zip
  2. Close ZRE if open
  3. Unzip ZRERuntimeBusinessLogic.zip into your ZRE installation location and replace the old one. (most commonly located in Program Files (x86)\Zeta Resource Editor)
  4. Open ZRE
  5. Refresh File List and wait for it to complete where all files are lit up. (This is so the File Group IDs will be generated correctly, just in case)
  6. Save the Project
  7. Viola! You are ready to export!

Please note that this MAY cause problems with importing older exports, in that the Filegroup IDs may not be the same.  This is unlikely though since you haven’t been able to export with the current version anyway.

Happy Translating!

Download as .key, then rename to .zip

Uninstalling Hyper-V Integration Services from converted Guest

26 Feb

Wanted to quickly migrate a couple of develpment Hyper-V VMs to Virtualbox.  The actual migration was rather simple.  I may blog on it’s simplicity in the future, but you can find lots on the net if needed.

After converting and firing up my vms in Virtualbox on a freshly configured host machine, I realized I had forgotten the important step of uninstalling the Hyper-V Integration Services before converting.  If you have found this blog, then you’re already aware that you cannot just uninstall this package in anything other than a guest hosted by Hyper-V.  Since I had reinstalled and configured a new machine without Hyper-V to use Virtualbox, I was in a pickle as I couldn’t readily load my vhd’s back into a Hyper-V host.

Now there are other suggestions on the web about messing with the hal.dll or some ideas with extracting the Integration Service installation package and working that direction.  But this approach seems to be the easiest and most straight forward.

My setup is Virtualbox on Windows 7 Ultimate with Server 2008 (not R2) guests.  But it will also work with other Windows hosts and guests but with minor navigational differences.

Steps to Uninstall Hyper-V Integration Services from converted Guest OS not hosted by Hyper-V:

These steps are to be performed within each Guest OS.
Do not perform these on the HOST.

  1. Use the following instructions to open the Device manager WITH the option of viewing non-connected devices
    – Open cmd prompt as administrator and run the following

    set devmgr_show_nonpresent_devices=1
    Start devmgmt.msc

  2. Device Manager: Click View menu -> Show hidden devices
  3. Start expanding ALL nodes and uninstall any devices that are greyed out (faded icons).  You will notice most are named msft virtual or similar.
    Tip:  The delete button will also uninstall.  So you can simply click and delete, click – delete and so on.
  4. Goto Control Panel – > Programs and Features – > View installed updates (left menu)
  5. Uninstall Hyper-V Guest Integration Services (KB956777).  Restart guest when prompted.  If not prompted, restart afterwards anyway.
  6. After restarting the Guest OS, reinstall the appropriate Integration services from your Virtual host platform for safe measure.  For Example, in Virtualbox Click Devices menu -> Install Guest Additions and proceed with reinstalling.  Then reboot the Guest OS again.

Note: When uninstalling the devices in DM, you will notice the Hyper-V service items under System Devices.  Once you have completely uninstalled ALL “disconnected” items in ALL nodes and performed steps 4-5, then the Hyper-V services in your Services Mgmnt console will be gone.

After rebooting, you should now have a clean VM with no Hyper-V stuff running in services.  If you repeat Step 1 now, you should also find that your system is clear of any Hyper-V device drivers.

Happy Virtualizing!