vsphere-automation-sdk-.net
vsphere-automation-sdk-.net copied to clipboard
feature request: .net standard
Any chance of the SDK becoming .net standard compatible?
I'd like to have the option of using it in .net core applications.
Thank you for your feature request. At the moment, there is no plan to publish .NET Standard compatible libraries for the SDK. But I'll definitely mention this to the team and if there is more interest regarding this, we will put this in the backlog.
We would also appreciate .Net Standard support.
Another vote for this, .net standard support would be very much appreciated
Another vote for .NET Standard would be great.
I'll have to use vmware/govmomi instead because I need xplat support.
You will probably need both the management sdk and the automation sdk dlls to be published to nuget in order to be able to use them. The latter doesn't have all the APIs. After some preliminary investigation, I found that the .NET Core WCF library doesn't support everything that the management SDK requires. Our partner team, PowerCLI, actually had to patch and maintain their own version of that library in order to use it. Given this situation, and other priorities, this is not currently on the radar. I'll let you know when I have more updates on this.
As the future of .NET is Core, I'd like to mention that .NET 4.8 is the last version of .NET based on "Framework".
.NET 5 will be based on the .NET Core lineage.
https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
I too am having to adopt govmomi because of the lack of .NET Core support.
this is not currently on the radar
how do we get it on the radar?
Just ran ApiPort.exe to verify compatibility. It seems as if at least vapi-runtime is almost .NET standard compliant:
Target type | Target member | Header for assembly name entries | .NET Core + Platform Extensions | .NET Core | .NET Standard + Platform Extensions | Recommended changes |
---|---|---|---|---|---|---|
T:System.Web.Script.Serialization.JavaScriptSerializer | T:System.Web.Script.Serialization.JavaScriptSerializer | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.#ctor | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.ConvertToType``1(System.Object) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.Deserialize``1(System.String) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.DeserializeObject(System.String) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.get_MaxJsonLength | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.RegisterConverters(System.Collections.Generic.IEnumerable{System.Web.Script.Serialization.JavaScriptConverter}) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.Serialize(System.Object) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptSerializer | M:System.Web.Script.Serialization.JavaScriptSerializer.set_MaxJsonLength(System.Int32) | vapi-runtime | Not supported | Not supported | Not supported | Use JSON.NET instead. |
T:System.Web.Script.Serialization.JavaScriptConverter | T:System.Web.Script.Serialization.JavaScriptConverter | vapi-runtime | Not supported | Not supported | Not supported | |
T:System.Web.Script.Serialization.JavaScriptConverter | M:System.Web.Script.Serialization.JavaScriptConverter.#ctor | vapi-runtime | Not supported | Not supported | Not supported |
I've just tried to write a small program listing VMs in a .NET core 3 application. Referencing the VAPI is simply done by referencing the prebuilt DLL files in this repo.
When starting the app, it complained about not being able to find System.Configuration.ConfigurationManager. This is no problem; that's easily installed via Nuget, and is available as a .NET standard compatible library.
The next error is harder though:
'Could not load file or assembly 'System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.'
System.Web.Extensions is not available for .NET core. So that is the part that will need to be rewritten.
Didn't really expect this to be a problem when logging in though. I was expecting some calls not to work correctly, but honestly, I wasn't expecting logging in to be a problem.
IMHO if the REST sdk was defined in a Swagger/OpenAPI document tooling could then be used to create a client from the Swagger/OpenAPI document and updated as when the documentation changes. SwaggerStudio is but one such tool that would/could be used.
@grahamehorner the vCenter Server Appliance comes with a built-in definition endpoint, you can find it at https://
@Rainmaker52 I have the same issue, did you solve it? Is the prebuild dll open source? Maybe we could modify it?
I have been able to reference the binaries (eg. VmWare.Vim.dll, VimService65.dll, vapi-client-bindings.dll, etc) in a .NET Core 3.1 project using Visual Studio 2019. How well they work remains to be seen, but the project builds so I am optimistic.
The SDK does seem to work in .NET Core 3.1 if you reference the libraries in a project in Visual Studio 2019! Too little, too late maybe, but for all of you .net die-hards, this may be useful.