IE shows binding in select instead of value using AngularJS

One of the bugs that was filed for an AngularJS part of our system was about a selectlist showing the binding in stead of the value for several options. As soon as stuff (options in this case) started moving around, it got even prettier…

select-gone-rogue.png

I’ve tried several solutions like using ng-value in stead of value and using the fixIE() solution that roams the internet. Unfortunately all to no avail. In the end, a solution was found. Let me share it so you don’t have to look for one as long as I did ;)

Original code

Our original code was in a directive that actually used two selectlists to facilitate moving values from one to another, enabling and disabling items. It looked something like this:

<div>
    <select ng-model="selectedLeft" multiple style="float: left; width:40%; height: 300px;">
        <option ng-repeat="option in selected track by $index" value="{{option}}">{{option | lowercase}}</option>
    </select>
    <section style="float: left; padding: 10px;">
        <button ng-click="moveRight()" ng-disabled="selectedLeft.length < 1">&gt;&gt;</button>
        <button ng-click="moveLeft()" ng-disabled="selectedRight.length < 1">&lt;&lt;</button>
    </section>
    <select ng-model="selectedRight" multiple style="float: left; width:40%; height: 300px;">
       <option ng-repeat="option in rightList track by $index" value="{{option}}">{{option | lowercase}}</option>
    </select>
</div>

Solution

In the end, changing the way we built up the select helped: in stead of using an ng-repeat on the option tag, we used ng-options on the select tag. This fixed the issue for us! The HTML of the directive looks like this now:

<div>
    <select ng-model="selectedLeft" multiple style="float: left; width:40%; height: 300px;" ng-options="option as option|lowercase for option in selected track by option">
    </select>
    <section style="float: left; padding: 10px;">
        <button ng-click="moveRight()" ng-disabled="selectedLeft.length < 1">&gt;&gt;</button>
        <button ng-click="moveLeft()" ng-disabled="selectedRight.length < 1">&lt;&lt;</button>
    </section>
    <select ng-model="selectedRight" multiple style="float: left; width:40%; height: 300px;" ng-options="option as option|lowercase for option in rightList track by option">
    </select>
</div>

Hope this helps.

.NET Core: not your daddy’s dotnet

On March 29, we (my colleague Oscar van Tol and myself) held a 2.5 hour presentation about .NET Core at the Betabit office in Rotterdam. We ended up having too much content for the evening, so we decided to host a hands-on workshop for those interested, where we not only show .NET Core, but also enable you to have a go at it yourself. The location will most probably be Utrecht (because it’s located more central). Stay tuned for more info on the details of the workshop.

About that evening: we had a lot of fun doing this talk and we’re looking forward to doing more in the future. You can find the presentation on Slideshare, the sourcecode we used for the demos (and then some…!) can be found on GitHub: https://github.com/betabitnl/nyddn.

Happy coding.

Creating Service Bus authorization rules with ARM errors out

Intro

In my current project we use Azure Resource Manager (ARM) templates to help with deployments across multiple subscriptions and environments. One of the elements of the ARM template is adding a couple of Shared Access Policies to enable Read and Write on the queues we have in place. The policies have been defined on Service Bus level because they span multiple queues.

Our ARM template functioned just fine, (automated) deployment was up & running and life was beautiful. Until our automated deployment to our development environment triggered in the night of January 24th. Our ARM template, not having been changed for a while, suddenly errored out with a Bad Request. The message read:

Request payload is not in the expected format.

Searching for the issue

We checked everything: API versions (still version 2015-08-01, so no changes there), variables we introduced (no changes there) and parameters. We even stripped out all dynamic behavior just to be sure that wasn’t the cause. And it wasn’t.

The offending part of the ARM template (the one that had functioned before) looked like this:
{
    "apiVersion": "2015-08-01",
    "name": "[concat(variables('servicebus_namespace_name'), '/', 'RoleName')]",
    "type": "Microsoft.ServiceBus/namespaces/authorizationRules",
    "dependsOn": [
"[concat('Microsoft.ServiceBus/namespaces/', variables('servicebus_namespace_name'))]"
     ],
    "location": "[variables('location')]",
    "properties": {
        "Rights": [
            //"Send",
            "Listen"
            //"Manage"
]
}
}

I found an article Create a Service Bus authorization rule for namespace and queue using an Azure Resource Manager template. One of the things in that article is an exmple, that also holds a piece of template to create an Authorization Rule on Service Bus level:

{
    "apiVersion": "[variables('sbVersion')]",
    "name": "[variables('namespaceAuthRuleName')]",
    "type": "Microsoft.ServiceBus/namespaces/authorizationRules",
    "dependsOn": ["[concat('Microsoft.ServiceBus/namespaces/', parameters('serviceBusNamespaceName'))]"],
    "location": "[resourceGroup().location]",
    "properties": {
        "Rights": ["Send"]
}
}

I put the two parts next to each other and started removing all differences between the two. Spacing, newlines… I made sure everything matched. And what do you know? The damned thing worked.

Several tries (and failures) later, I now know what caused our ARM template to fail. It were the comments in the Rights element.

Solution

In the end, the only thing I had to do to get our template working again was remove the comments in the Rights element. I did try with several different comments (with and without a comma in there, for instance) but the comments I tried all made the template fail. As said earlier, the template worked earlier, including the comments. The fact that there are comments all over the place in our ARM template makes it even stranger…

Hope this helps.

By |February 1st, 2017|ARM, automation, azure, Error|0 Comments

Unable to attach remote debugger after Visual Studio 2015 Update 2

As the title states: I was unable to attach the remote debugger (for instance to an Azure Web App) after installing Visual Studio 2015 Update 2. I got an error with something about invalid memory access or something like that.

The solution is simple: install Remote Tools for Visual Studio 2015 Update 2. Go to the webite, pick your machine’s architecture (the x86 install won’t run on a x64 machine) and click download. After installing, you’re good to go!

Hope this helps.

PS: There’s a list of Related releases on the Visual Studio 2015 Update 2 page. Have a look, it’s helpful ;)

Unable to find specific NuGet packages after update

After updating Visual Studio 2015 (there was an update for GitHub Extensions, one for the NuGet Package Manager and, of course, there was Visual Studio 2015 Update 2) I tried to add the WindowsAzure.Storage NuGet package to a project I started about a month ago. I opened NuGet Package Manager, went to the Browse tab and typed WindowsAzure.Storage. The result: No Packages Found. OK, so then I’ll just….

Wait… WHAT?

No Packages Found

After doing all sorts of things, including looking for other NuGet packages with the same result, I found what the issue seemed to be: the Package Sources weren’t up to par, since the Official feed had vannished. I fixed them to look like this:

NuGet Package Sources

And then set the’Package source’ to be ‘All’ in the upper right corner of the NuGet Package Manager. Fixed it for me!

Hope this helps.

 

Exception with EF code first migrations

Just ran into an exception when running both update-database and add-migration in the Package Manager Console for an EF Code First project. The Exception read:

The type initializer for ‘System.Data.Entity.Migrations.DbMigrationsConfiguration`1’ threw an exception.

The cause? An invalid config file for the project I was trying to run the tools for. So: if you run into this exception, check your configs ;)

By |March 18th, 2016|Development, Error|3 Comments

Running Visual Studio as an administrator causes ‘Save changes to devenv.sln’ when double clicking solutions

After making sure my Visual Studio always ran as an administrator by following my own post HowTo: Have Visual Studio always run as administrator on Windows 8, I got a message if I wanted to save changes to devenv.sln each and every time I double clicked a Solution. Since the problem kept occuring after installing Visual Studio 2015 CTP6, I wanted to solve it. So here we go!

Double clicking a Solution file doesn’t start devenv.exe (which is set to be run as an administrator) but will cause the Microsoft Visual Studio Version Selector (VSLauncher.exe) to be run. This tool selects the right version of Visual Studio to open the Solution. Because VSLauncher.exe is not being run as an administrator, the error occurs.

The Solution

Find VSLauncher.exe, which is typically located at ‘C:\Program Files (x86)\Common Files\Microsoft Shared\MSEnv’ and make sure it runs as an administrator too. This will cause the Version Selector to be started with the correct privileges, helping it start devenv.exe with the right privileges. Problem solved ;)

Hope this helps

Scheduled build launches an hour early on TFS 2013 (after installing Update 3 or 4)

There’s new information in this issue. Please read the updates at the bottom of the article.

We use our own TFS server and were using TFS 2013 Update 2 up until last Tuesday. We have several build definitions for my current project, and most of them are scheduled at a specific time, because we have specific times for automatic deployment. Up until Tuesday, everything seemed to work well and the Builds ran at the specified time (both before and after Daylight Saving Time applied).

And then I installed Update 4… :)

The issue

After installing Update 4, our scheduled builds ran an hour early. Of course I checked both the time on the server and the time the build was scheduled for: these were fine. I looked at the Update 4 documentation, but couldn’t find anything related. I did see however the build server report its time setting as UTC +01:00, and the build definition stating UTC +02:00.
Next up was searching the web, which pointed me to an article on connect.microsoft.com: Scheduled build launched 1 hour earlier. As a comment on this article, which is from July last year, Microsoft employee Mario mentions the issue is fixed in the (at that time) RC of the Summer Update. He also mentions:

Once you install that Update on the server please recreate/re add the build definition and the database will now respect the right times.

Visual Studio 2013 Update 3 & 4

Since we were using Update 2, I looked at the documentation of both Update 3 and Update 4. And if you go to the New technology improvements in Visual Studio 2013 Update 3 chapter and look at the Fixed issues paragraph you find this for Team Foundation Server:

Scheduled builds may run an hour early after daylight saving time.

This led me to believe the update Mario was talking about July last year was part of Update 3. Which might be the cause of our issues.

The solution – Quick & Dirty

To get our builds to run at the scheduled times, we used a real obvious and Quick & Dirty solution: we shifted the scheduled times of the builds an hour, so they run at the time we expect them to run, not the time they are scheduled to run (??!?!?).
There are some downsides to this solution, like the builds not running at their scheduled time, but an hour early. That’s not logical. So you should document / communicate it well. Another downside is I expect the build won’t run at the right time after Daylight Saving Time.

The REAL solution

I created a new build definition that was scheduled at a specific time. And it ran at the specified time. Since Update 3 solves this issue, I expect it to run at the same time after Daylight Saving Time.

So the only REAL solution is to re-create your build definitions.

Scenarios

I think (but am not sure) the following scenarios apply:

Build definition created inBuild definition running inResult
Update 2Update 2Works fine (?)
Update 3 / 4Update 3 / 4Works fine
Update 2Update 3 / 4Trouble in paradise

References

For details about the updates, have a look at the Description of Visual Studio 2013 Update 3 and Description of Visual Studio 2013 Update 4.
You can find the Connect article over at Scheduled build launched 1 hour earlier.

UPDATE April 9 2015 16:15

It seems like it’s enough to edit (something small in) the build definition and save it to TFS again. The builds for which we shifted the time now build at the shifted time.
I’ve set the time for the scheduled builds to their original value and hope I can add a second update here tomorrow saying all is well…

UPDATE April 10 2015 09:45

Just to confirm, like Bryan MacFarlane states below: changing something small and saving your build definition is enough to fix this issue. So the impact is minor. Emoticon met brede lach

By |April 9th, 2015|TFS|1 Comment

Error saving Galileo Wiring App in Visual Studio

'The operation could not be completed' error when saving Galileo Wiring AppLast week I received my Intel Galileo board (from windowsondevices.com) and I started playing with developing for it yesterday. I created a first test project, but it didn’t run. Visual Studio couldn’t find the Arduino header file, which was probably due to a missing NuGet package (the Galileo C++ SDK). I tried to save the project, because you need to before you can manage NuGet packages, but to no avail. Visual Studio served me a ‘The operation could not be completed’ error without any additional information.

imageA while ago I posted about some handy settings in Visual Studio like Zero-impact projects & Cutting/copying empty lines. Turns out that the Windows for IoT project template does some extra things upon creation. And with the ‘Save new projects when created’ checkbox unchecked, it’s not able to do that. Rendering the project unsaveable…

 

The solution

It’s as easy as it is ugly to have to do this: simply check the checkbox in ‘Save new projects when created’ before creating your Windows for IoT project. Then you’re good to go…!

Hope this helps

Fixing the Remote Desktop Connection to a Virtual Machine in Microsoft Azure

A few minutes before my second session at the Dutch Techdays started I tried connecting to my Virtual Machine in Microsoft Azure through remote desktop. It didn’t connect… The RDP client tried to connect to the Virtual Machine, but nothing happened.

So I rebooted the VM and tried connecting again, confident that this would solve the problem. It didn’t connect…. again. As I started stressing out a bit (the VM was the main character of my session) I thought of one last thing I could try.

Fixing the issue

The next steps helped me save my Virtual Machine without too much loss of time (I was able to connect again just before the start of my session!):

  • Go to the Azure Management Portal
  • Open up the details of the VM you’re having trouble with
  • Go to the ENDPOINTS tab (see image below)
  • Select the ‘Remote Desktop’ endpoint and click EDIT at the bottom of the screen
  • Change the public port to a different (random) number
  • Wait for the changes to be propagated
  • Success!

Azure Management Portal

Hope this helps.