sfeldman.NET

Do you need to create an Azure Function based on an existing one? While there's no a way to do this using the portal, I found it a temporary workaround. Head to the SCM portal (kudu portal). If you functions project is called X, then that would be https://x.scm.azurewebsites.net.

Cloud Services (CS), then WebApps (formerly Web Sites), then WebJobs, and now Azure Functions. Are Functions to replace the predecessors? Well, before we jump into conclusion and "function" it all, I wanted to find where functions would make sense. Among the things I do, I maintain a repository that has a dependency on Azure Service Bus (ASB). Whenever a new version of ASB is released, I'd like to get notified. Yes, there are services to achieve it. Though, imagine there are none. This kind of "service" is a self-contained. Very simple functionality and dependencies. The behavior is clear: detect if there's a new version of the package. If there's one, send a notification (email). Repeat the procedure every given period.

Testing code that involves queues always has some utility code that is responsible for test cleanup. The cleanup is often implemented as a queue purge operation. For example, MSMQ allows to delete all messages in a queue by calling a Purge() command on a queue.

How often do you write code and think about what will it look like the compiler is done with it? If you're like me, not often. But is it a good thing that over the time we've learned to trust unquestionably the compiler and blindly rely on it to do the job for us?

I was reading a question on StackOverflow where the requirement was to "Lock a Service-Bus Queue and prevent others from accessing it." Quite often when dealing with competing consumers and PeekLock mechanism it feels odd. What do you mean I'm in the middle of processing my message and it will re-appear on the queue?! Why do I need to worry about some LockDuration?! The answer is simple. The server allows the receiver to handle the message and completes it within LockDuration time. If the operation takes longer, the server will no longer respect the original lock token as it will be replaced by another receiver that got the message.

I tend to keep connection strings, security tokens, and other secrets in the environment variable. This is handy when you commit your code to a public repository and want to make sure that your storage account connection string is not shared worldwide. It's also convenient because all those variables can be accessed in almost any hosting environment (VM, Cloud Service, WebJob, Azure Function, you name it). The downside - getting to those environment variables fast to modify those.

Azure Service Bus still can't be created at the new portal, aka Ibiza. To create Azure Service Bus namespace and create entities, one has to do in manually at the old portal. That wouldn't be so bad, but the lack of controlling what Resource Group the new namespace will belong to is a slight impediment for those that like their resources to be at the right places.

Today have run into an interesting issue: a cloud service deployed with a 3rd party assembly version X was failing. The exception was indicating that version X-1 of the assembly was deployed. Looking at the project packages.config could see nothing but version X of the assembly. Quite a mystery.