Getting lots of "Unable to aquire Singleton lock" during localhost development

Heya 😃

So I’ve just started playing around / trying to use the TimerTrigger with a new webjob. I’m doing localhost development to make sure the code works, before I deploy it up to Azure.

To do this, I click F5 to Debug my webjob console app. Ok, great! works/etc… I then stop this (or the code throws an exception and crashes).

I then change one tiny thing and then hit F5 again … and then get this:

Sometimes, I wait 10 or even 20 seconds after the webjob stopped/stops and then hit F5 and still get that error.

Shouldn’t the host 100% tear down after it’s stopped? I should be able to hit F5, then close app, then hit F5 straight away, right?

Update / More info.

Here’s my program.cs as a reference:

    class Program
    {
        // Please set the following connection strings in app.config for this WebJob to run:
        // AzureWebJobsDashboard and AzureWebJobsStorage
        static void Main()
        {
            var config = new JobHostConfiguration();
            config.Tracing.ConsoleLevel = TraceLevel.Verbose;

            config.UseTimers();

            var host = new JobHost(config);
            host.RunAndBlock();

            //var host = new JobHost();
            //// The following code ensures that the WebJob will be running continuously
            //host.RunAndBlock();
        }
    }

[mathewc]

Ok, I’ve added JobHostConfiguration.IsDevelopment and JobHostConfiguration.UseDevelopmentSettings(). You can see an example in the extensions sample here. This new method sets up all the optimal local dev settings as mentioned above.

See the xml doc on these new methods for details. Basically if your environment has a setting AzureWebJobsEnv, IsDevelopment will be true. Note that these changes are in prerelease packages available on myget.

[PureKrome]

The intent is for you NOT to have to discover anything about these low level details. It should just work for people

I’m all for that 😃 Was just thinking about options, but yes! all for that 😃

One option would be for the SDK to use a lower default lease period when running locally This I really like. But … how do you define ‘locally’ ? via the connection string?

e.g.: <Setting name="AzureConnectionString" value="UseDevelopmentStorage=true" />

However, this would work well for the “getting started” case where a person is only running locally at the time. That’s the use case I’m mainly targetting in this issue - so yep 😃