Recently I was opening a Angular2 application that was using the WebPack Sass loader to bundle the Sass files. Conveniently Visual Studio performs “npm install” to load all the npm packages.
When running “npm start” I got the following error:
Node Sass could not find a binding for your current environment: Windows 64-bit with Node.js 6.x
Found bindings for the following environments:
- Windows 32-bit with Node.js 5.x
This usually happens because your environment has changed since running `npm install`.
Run `npm rebuild node-sass` to build the binding for your current environment.
Somehow Visual Studio installed the wrong binaries for node-sass. The fix was quite simply – just run “npm rebuild node-sass” as stated in the error message.
Did anyone else experience the same behaviour?
RavenDB becomes more and more popular among .NET developer. The simple to use C# Api makes it a good choice for many project that require a fast persistence layer.
The JSON that is stored, can be customize using JSON.NET attributes. But sometimes you annotate your data POCOs and nothing happens e.g.
- You put [JsonIgnore] on a property but it still appears in the created JSON
The reason is simple: The RavenDB team decided to put a copy of JSON.NET in the RavenDB dll and only the attributes from this “special” namespace are used for the JSON handling. So if you want to customize the JSON in the database, always use attributes from the Raven.Imports.Newtonsoft.Json namespace.
Recently, I installed a new laptop with Visual Studio and the “normal” tool chain. While doing this, I encountered a strange error when installing the .NET Core tools.
Setup has detected that Visual Studio 2015 Update 3 may not be completely installed. Please repair Visual Studio 2015 Update 3, then install this product again.
However, repairing Visual Studio did not solve the problem. Luckily, I found this StackOverflow post. The problem could easily be solved by starting the setup on the command line with this command:
Angular2 requires a bunch of files to setup and things to configure. To avoid unnecessary typing and copying of files the angular guys created angular-cli which allows bootstrapping a new Angular2 application with just one line:
ng new my-fancy-app
When installing the angular-cli package using:
npm install -g angular-cli
I encountered a strange error message that stated:
ng: command not found
There is this discussion on Github but all comments there did not solve the issue for me. Finally I noticed that the ng-command is not linked in /usr/local/bin. The fix for my problem was to add it via:
ln -s /usr/local/Cellar/node/6.3.1/lib/node_modules/angular-cli/bin/ng /usr/local/bin/ng
Bamboo is a great build server and the possibility to use EC2 instances as build agents makes it really cost efficient and flexible. But – most of the time, the stock images provided by Atlassian need to be customized to fit the purpose. But how to do this properly?
The easiest way is to create a new AMI based on the stock images and customize it.
- Launch a new instance using on of the existing AMIs (e.g. ami-ed6deb9e for the Ubuntu stock image) or use an instance launched by Bamboo
- Connect to it using SSH and customize it.
- Open the EC2 management console, select the instance and choose Actions -> Image -> Create Image
- Afterwards you need to enter a name and choose Create Image
- Copy the AMI id
- Switch back to Bamboo and navigate to Bamboo administration -> Image configurations
- Create a new configuration using the AMI id you copied before
- You can now launch build agents with you custom setup
I was setting up a static website on Amazon S3. This process is fairly simply. Finally I wanted to create an user that can only deploy this one single bucket. As with all other user accounts I wanted to follow the least privilege model. So the default S3-Full Access policy was not an option for me.
I created a new policy granting full access to this specific bucket. It looked like this:
I assigned this to the user that uploads my site and started the upload. Peng! Access Denied.
After some investigation I discovered that the ListAllMyBuckets action is causing that problem. I added a second policy:
This solved my issue and the upload work fine.
Today I had a SharePoint installation that started to throw errors when opening the User Profile Service Application. After examining the ULS log I noticed this log entry:
Requested registry access is not allowed.
So something with the permissions in the registry seemed to be wrong. I manually browsed through the registry settings and compared them to another, working installation but I couldn’t find anything. Luckily I stumbled across this cmdlet: Initialize-SPResourceSecurity I ran the cmdlet and everything started to work fine again.