628426
My feedback
-
2 votes628426
shared this idea
·
-
3 votes628426
shared this idea
·
-
58 votes
We are currently investigating the opportunities around shipping more features as NuGet packages. We have opened up far more areas as NuGet packages than in previous releases. That said, the idea of creating a NuGet package that contains the emulator is a large effort. As we progress towards this goal or realize that it isn’t possible I’ll update the forum thread.
For the time being, rest assured we’ve heard this comment, which has been echoed by the larger Windows Azure community. As an Azure developer myself I find merit in this request and feel there is a good chance it could eventually be realized.
An error occurred while saving the comment 628426
supported this idea
·
-
5,138 votes
Thank you for the continued feedback on this request. We’re evaluating this support in the context of various storage services and connectivity mechanisms.
An error occurred while saving the comment 628426
commented
I am not an expert, hardly even an enthusiastic amateur, however my understanding is, to support this:
- you would need to give your private key to Azure
- or alternatively the Azure ops team would need to be able to apply for SSL cert using your top level domain
- or the Azure platform could generate a certificate using your custom domain name and clients would receive certificate warnings
- or Verisign/Thawte would need to provide the Azure team with their private key for them to generate legit certificatesIf my understanding is correct, none of these options is something I would be comfortable with. Happy to be educated if there is indeed a secure way to achieve this.
The friction between multiple installed version of the SDK, projects directly referencing %PROGRAMFILES&/Azure SDK/2/2.1 etc, as well as using NUGET for Storage Client is a real headache. I vote for the SDK to be all NUGET based, and developers who want them download the tools (emulator, VS add-in)