Many developers prefer to strong name sign their assemblies. The reason for this is to establish trust with the consumers of their applications: the signature proves that the code was built by the person who claims to be the author, and can be verified using
a certificate. Signing code also means that the dependencies that are consumed must be signed. Not all third-party dependencies are signed, though, for example when consuming packages from
NuGet. Some are signed, some are unsigned, and the only way to know is when at compile time when we see this:
That’s right: a signed assembly cannot consume an unsigned one. Now what if we really need that dependency but don’t want to lose the fact that we can easily update it usign NuGet… Turns out there is a NuGet package for that!
The Assembly Strong Naming Toolkit can be installed into our project, after which we can use the NuGet Package Manager Console to sign referenced assemblies. There is also the
.NET Assembly Strong-Name Signer by Werner van Deventer, which provides us with a nice UI as well.
The problem is that the above tools only sign the assemblies once we already consumed the NuGet package. With package restore enabled, that’s pretty annoying as the assemblies will be restored when we don’t have them on our system, thus restoring unsigned
Based on the
.NET Assembly Strong-Name Signer, I decided to create a
small utility that can sign all assemblies in a NuGet package and creates a new package out of those. This “signed package” can then be used instead of the original, making sure we can simply consume the package in Visual Studio and be done with it. Here’s
some sample code which signs the package “MyPackage” and creates “MyPackage.Signed”:
Code highlighting produced by Actipro CodeHighlighter (freeware)
-->var signer = new PackageSigner();
<!-- Code inserted with Steve Dunn's Windows Live Writer Code Formatter Plugin. http://dunnhq.com -->
This is pretty neat, if I may say so, but still requires manual intervention for the packages we consume. Unless the NuGet feed we’re consuming could sign the assemblies in the packages for us?
NuGet Signature meets MyGet Webhooks
Earlier this week, MyGet announced their
webhooks feature. After enabling the feature on our feed, we could pipe events, such as “package added”, into software of our own and perform an action based on this event. Such as, signing a package.
Sweet! From the GitHub repository here, download the Web API project and deploy it to Microsoft Azure Websites. I wrote the Web API project with some configuration options, which we can either specify
before deploying or through the management dashboard. The application needs these:
- Signature:KeyFile - path to the PFX file to use when signing (defaults to a sample key file)
- Signature:KeyFilePassword - private key/password for using the PFX file
- Signature:PackageIdSuffix - suffix for signed package id's. Can be empty or something like ".Signed"
- Signature:NuGetFeedUrl - NuGet feed to push signed packages to
- Signature:NuGetFeedApiKey - API key for pushing packages to the above feed
The configuration in the Microsoft Azure Management Dashboard could look like the this:
Once that runs, we can configure the web hook on the MyGet side. Be sure to add an HTTP POST hook that posts to
<url to your deployed app>/api/sign, and only with the package added event.
From now on, all packages that are added to our feed will be signed when the webhook is triggered. Here’s an example where I pushed several packages to the feed and the NuGet Signature application signed the packages themselves.
The nice thing is in Visual Studio we can now consume the “.Signed” packages and no longer have to worry about strong name signing.
Thanks to Werner for the
.NET Assembly Strong-Name Signer I was able to base this on.
WebStorm will be splendid at that part. It provides a project system, code completion, navigation, inspections to check whether my code is as it should be (which from the screenshot below, it is not, yet ;-)) and so on.
What I like a lot is that everything related to the device-side of my project (a thermometer thing that posts data to the Internet), is in one place. The project system ensures the IDE can be intelligent about code completion and navigation, I can see the
npm modules I have installed, I can use version control and directly push my changes back to a GitHub repository. The Terminal tool window lets me run the Tessel command line to run scripts and so on. No fiddling with additional tools so far!
Tessel Command Line Tools
As I explained in a previous blog post, the Tessel comes with a command line that is used toconnect the thing to WiFi, run and deploy scripts and read logs off it (and more). I admit it: I am bad at command line things. After a long time, commands get engraved
in my memory and I’m quite fast at using them, but new command line tools, like Tessel’s, are something that I always struggle with at the start.
To help me learn, I thought I’d add the Tessel command line to WebStorm’s Command Line Tools. Through the
Project Settings | Command Line Tool Support,, I added the path to Tessel’s tool (%APPDATA%\npm\tessel.cmd). Note that you may have to install the
Command Line Tools Plugin into WebStorm, I’m unsure if it’s bundled.
This helps in getting the Tessel commands available in the Command Line Tools after pressign
Ctrl+Shift+X (or Tools | Run Command…), but it still does not help me in learning this new command’s syntax, right? Copy
this gist into
C:\Users\<your username>\.WebStorm8\config\commandlinetools\Custom_tessel.xml and behold: completion for these commands!
Again, I consider them as training wheels until I start memorizing the commands. I can remember
tessel run, but it’s all the one’s that I’m not using cntinuously that I tend to forget…
Running Code on the Tessel
Running code on the Tessel can be done using the tessel run <script.js>
command. However, I dislike having to always jump into a console or even the command line tools mentioned earlier to just run and see if things work. WebStorm has the concept of Run/Debug Configurations, where using a simple keystroke (Shift+F10)
I can run the active configuration without having to switch my brain context to a console.
I created two configurations: one that runs nodejs on my own computer so I can test some things, and one that invokes
tessel run. Provide the path to node, set the working directory to the current project folder, specify the Tessel command line script as the file to execute and provide
run somescript.js as the parameters.
Quick note here: after a few massive errors coming from Tessel’s command line tool that mentioned the device only supports one connection, it’s bes tto check the
Single instance only box for the run configuration. This ensures the process is killed and restarted whenever the script is ran.
Save, Shift+F10 and we’re deploying and running whenever we want to test our code.
Debugging does not work, as the Tessel does not support this. I hope support for it will be added, ideally using the V8 debugger so WebStorm can hook into it, too. Currently I’m doing “poor man’s debugging”: dumping variables using
When I first added Tessel to WebStorm, I figured it would be nice to have some menu entries to invoke commands like updating the firmware (a weekly task,Tessel is being actively developed it seems!) or showing the device’s WiFi status. So I did!
External Tools can be added under the IDE Settings | External Tools and added to groups and so on. Here’s what I entered for the “Update firmware” command:
It’s basically just running node, passing it the path to the Tessel command line script and appending the correct parameter.
Now, I don’t use my newly created menu too much I must say. Using the command line tools directly is more straightforward. But adding these external tools does give an additional advantage: since I have to re-connect to the WiFi every now and then (Tessel’s
WiFi chip is a bit flakey when further away from the access point), I added an external tool for connectingit to WiFi and assigned a shortcut to it (IDE Settings | Keymaps, search for whatever label you gave the command and use the
context menu to assign a keyboard shortcut). On my machine, Ctrl+Alt+W resets the Tessel’s WiFi now!
Installing npm Packages
This one may be overkill, but I found searching npm for Tessel-related packages quite handy through the IDE. From
Project Settings | Node.JS and NPM, searching packages is pretty simple. And installing them, too! Careful, Tessel’s 32 MB of storage may not like too many modules…
Fun fact: writing this blog post, I noticed the grunt-tessel package which contains tasks that run or deploy scripts to the device. If you prefer using Grunt for doing that, know WebStorm comes with a
Grunt runner, too.
That’s it, for now, I do hope to tinker away on the Tessel in the next weeks nad finish my thermometer and the app so I can see the (historical) temperature in my house,