my understanding is that with remote desktop enabled, it requires separate file containing the credentials
mmmh I think I should manually upload the certificate, VS prompts me to do so if I deploy manually
wonder if it wouldn't require to extend https://github.com/mbraceproject/MBrace.Azure/blob/master/src/MBrace.Azure.Management/Compute.fs#L284 to work with remote desktop so I would be able to pass additional properties (mentionned in the error message)
it would also require an option .pfx file and associated password to work (assuming it would add the certificate like it can be done in the classic console)
I'm leaving idea of using remote desktop for now, and try to setup another cspkg with just my tcp port
why do you want to use remote desktop?
I often just use mbrace to perform adminstrative stuff on my nodes
processes run with admin rights so you can do whatever you want with the nodes' state
I need each node of the cluster to have one tcp port open to outside the cluster/cloud service, ideally only accepting connections from a given host, but for now I'd like to have it work without restrictions, I've added a InputEndPoint
<InputEndpoint name="MyEndPoint" protocol="tcp" port="22222" />
is there a plan to move mbrace.azure to most recent azure APIs (https://github.com/Azure/azure-sdk-for-net), I intend to use those bits in my .net codebase and it is confusing to have all those Microsoft.WindowsAzure.* + Microsoft.Azure dependencies
I'm slowly figuring things out on all the bits I need to use and the azure development story is a bumpy ride (took me very long to find what is most recent SDK bits, but almost no documentation for it), departing from "complete azure newbie" involves lots of tedious searches in a jungle of APIs, outdated blog posts, msdn doc lagging a lot in showing the current SDK, and frustrating trial/errors to setup authorizations (need to setup classic AD for using most of that azure-sdk-for-net stuff)
and they will be seeing eachother
Hi @eiriktsarpalis regarding Azure SDK versions, I believe all "WindowsAzure" dependencies are going to be deprecated by new bits (https://github.com/Azure/azure-sdk-for-net), I believe for all the aspects which are exposed under new assemblies (probably storage / Service bus as you mention, but maybe other as well) we should try to favor those.
I'm currently working with pre-release packages because stuff is being added actively just to make sure I don't go and implement my own rest client if something is being handled in their new SDK
right now (not mbrace related) I can't manage classic VM with the new SDK (and with old SDK, there is nothing too, I need to send handcrafted HTTP Requests)
if MBrace can migrate away from azure "classic" services wherever it is possible, I think it will now be possible to leverage their better SDK
nevermind, service bus is there: https://github.com/Azure/azure-sdk-for-net/tree/master/src/ServiceManagement/ServiceBus/ServiceBusManagement still under WindowsAzure namespace
which is separate to the function of WindowsAzure.* libraries
MBrace.Azure uses WindowsAzure.* libraries
MBrace.Azure.Management uses the latter
I'm still trying to make the virtualnetwork configuration work from my custom .cspkg, I noticed that when I create a cloud service from classic azure portal, it would ask for both .cspkg and .cscfg files, so I suspect that somehow mbrace should accept both those files instead of just .cspkg
https://github.com/mbraceproject/MBrace.Azure/blob/master/src/MBrace.Azure.Management/Compute.fs#L202 This is called even when I give a cspkg, and it would conflict with the custom configuration I intend to pass (which has a NetworkConfiguration section)
the service definition is honored (since it ends in the .cspkg) but my custom configuration can't be passed
I still get an exception. Shall I post it at the github issue or here?