Issue pushing custom script extension via Fluent SDK

[azure]

Issue pushing custom script extension via Fluent SDK

[hovsepm]

@slawlor

As you are using Fluent SDK - could you provide us some info on why did you end up using Inner types? And also how did you create the ComputeClient in your sample?

We do have the Fluent flow for defining custom script extension like this:

IVirtualMachine windowsVM = azure.VirtualMachines.Define(windowsVmName)
        .WithRegion(Region.USEast)
        .WithExistingResourceGroup(rgName)
        .WithNewPrimaryNetwork("10.0.0.0/28")
        .WithPrimaryPrivateIPAddressDynamic()
        .WithNewPrimaryPublicIPAddress(pipDnsLabelWindowsVM)
        .WithPopularWindowsImage(KnownWindowsVirtualMachineImage.WindowsServer2012R2Datacenter)
        .WithAdminUsername(firstWindowsUserName)
        .WithAdminPassword(firstWindowsUserPassword)
        .WithSize(VirtualMachineSizeTypes.StandardD3V2)
        .DefineNewExtension(windowsCustomScriptExtensionName)
            .WithPublisher(windowsCustomScriptExtensionPublisherName)
            .WithType(windowsCustomScriptExtensionTypeName)
            .WithVersion(windowsCustomScriptExtensionVersionName)
            .WithMinorVersionAutoUpgrade()
            .WithPublicSetting("fileUris", mySQLWindowsInstallScriptFileUris)
            .WithPublicSetting("commandToExecute", mySqlScriptWindowsInstallCommand)
        .Attach()
        .Create();

you can browse the full code here - https://github.com/Azure-Samples/compute-dotnet-manage-virtual-machine-using-vm-extensions/blob/master/Program.cs#L208
or clone working project from here - https://github.com/Azure-Samples/compute-dotnet-manage-virtual-machine-using-vm-extensions

[hovsepm]

This seems to repro on the autogenerated SDK side and seems to be spec/autorest issue.
@olydis could you take a look? Do we even support object type serialization or compute swagger should be fixed first to exclude object types?

[olydis]

huh, I'd expect this to be serialized by Newtonsoft.JSON like anything else, but will take a look!

[olydis]

@hovsepm @slawlor I cannot reproduce the issue, i.e. I can successfully serialize things even without a strong type. Specifically, I made calls to VirtualMachineExtensionsOperations.CreateOrUpdate (regular SDK), passing

var ext = new VirtualMachineExtension();
ext.Location = "Location";
ext.Settings = new Dictionary<string, object> { { "commandToExecute", "asd" } }; // pass via dictionary
ext.ProtectedSettings = new someType { commandToExecute = "qwe" }; // pass via some own type

and get

{
  "properties": {
    "settings": {
      "commandToExecute": "asd"
    },
    "protectedSettings": {
      "commandToExecute": "qwe"
    }
  },
  "location": "Location"
}

on the wire, which is exactly as I would expect.

Hovsep probably has more information about the fluent part of it, but I am now wondering: What are you setting Settings/ProtectedSettings to precisely (before you went the strongly typed route)? After all, note that someType (in my case defined as class someType { public string commandToExecute { get; set; } }) could be annotated in ways that will mess with serialization - so how exactly did you try to pass the "commandToExecute"?

[slawlor]

So I was constructing my extension arguments as:

var extensionProp = new VirtualMachineExtensionInner
{
	Location = Config.Configure.Location,
	VirtualMachineExtensionType = "CustomScriptExtension",
	Publisher = "Microsoft.Compute",
	TypeHandlerVersion = "1.9",
	AutoUpgradeMinorVersion = true,
	Tags = new Dictionary<string, string>
	{
		{"DisplayName","Initiate-Training-Procedure"}
	},
	Settings = new
	{
		FileUris = new List<string>
		{
			scriptRef.Uri.AbsoluteUri
		}
	},
	ProtectedSettings = new
	{
		CommandToExecute = $"powershell -ExecutionPolicy Unrestricted -File ./{Config.Configure.TrainingFile} -accountName {account.AccountName} -key {Config.Configure.VmStorageKey} -endpoint {Config.Configure.VmStorageEndpoint}",
		StorageAccountName = account.AccountName,
		StorageAccountKey = account.ExportBase64EncodedKey()
	}
};

I hadn't defined an explicit class to the extra arguments, I was just creating an inline object. Perhaps that's the problem?

[anuchandy]

The concrete type of public and protected settings of an extension has to be dictionary, though the type is object in the VirtualMachineExtensionInner model.

Can you try the following?

IDictionary<string, object> publicSettings = new Dictionary<string, object>();
List<string> fileUris = new List<string>()
{
    scriptRef.Uri.AbsoluteUri
}
publicSettings.Add("fileUris",  fileUris);

IDictionary<string, object> protectedSettings = new Dictionary<string, object>();
protectedSettings.Add("commandToExecute", $"powershell -ExecutionPolicy Unrestricted -File ./{Config.Configure.TrainingFile} -accountName {account.AccountName} -key {Config.Configure.VmStorageKey} -endpoint {Config.Configure.VmStorageEndpoint}");
protectedSettings.Add("storageAccountName", account.AccountName);
protectedSettings.Add("storageAccountKey", account.ExportBase64EncodedKey());

var extensionProp = new VirtualMachineExtensionInner
{
	Location = Config.Configure.Location,
	VirtualMachineExtensionType = "CustomScriptExtension",
	Publisher = "Microsoft.Compute",
	TypeHandlerVersion = "1.9",
	AutoUpgradeMinorVersion = true,
	Tags = new Dictionary<string, string>
	{
		{"DisplayName", "Initiate-Training-Procedure"}
	},
	Settings = publicSettings,
	ProtectedSettings = protectedSettings
};

Regarding the storage account key, not sure what exactly ExportBase64EncodedKey method is doing, but you can simply specify the one of the key returned by the Azure Storage List Key API as it is.

[hovsepm]

@olydis @anuchandy @slawlor The issue is the anonymous type. So basically this construct

	Settings = new
	{
		FileUris = new List<string>
		{
			scriptRef.Uri.AbsoluteUri
		}
	},

will not be serialized and no exception will be thrown.

@slawlor Could you use the workaround advised by @anuchandy while we will look deeper into the issue?

[slawlor]

No problem, I'll stick to a Dictionary<String,Object>. Thanks for the assist.

[slawlor]

We created the compute client by instantiating a new

Microsoft.Azure.Management.Compute.Fluent.ComputeManagementClient 

but from looking at your sample we might be able to generalize that to the proper Fluent SDK. When we initially wrote this block we were trying to minimize dependencies to just what was necessary and the dev who did the work ruled out using the wrapper library for some reason (he no longer works here).

A lot of this is legacy (pre .netcore 2.0) code and we'll try and update it. Readability will get better too which is another plus.

Thanks for the help.

[hovsepm]

FYI we have a lot of sample that may be useful for your scenarios. Please check https://github.com/Azure/azure-libraries-for-net/blob/master/README.md the front page of the repo. It has a lot of sample links.