Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complete Support for .NET #3470

Open
lukehoban opened this issue Nov 7, 2019 · 0 comments
Assignees
Labels
Milestone

Comments

@lukehoban
Copy link
Member

@lukehoban lukehoban commented Nov 7, 2019

.NET is broadly supported in preview as of Pulumi 1.5 馃帀

This issue tracks remaining work to complete the support for .NET.

Done:

In progress:

  • Add .NET tests to provider repos
  • Apply improved namespace naming to all other providers (except AWS, Azure, AzureAD).
  • Set the csproj file name to the project name when created from a template (CLI change done, templates to be changed)

Need review:
(none)

TODO:

  • API docs at https://www.pulumi.com/docs/reference/pkg/.
  • Add Windows test coverage for some subset of .NET examples
  • add the work for TerraformRemoteState in pulumi-terraform
  • Mixins: ArchiveFunctionApp.
  • Testing Pulumi .NET programs - example, blog, any required support in the library
  • Get rid of Serilog dependency, use MS logging extensions

Investigate/design/think:

  • Add support for the new language to tf2pulumi
  • Dynamic Providers
  • Commit version.txt to git with some sensible version in it to make it easy to compile and run .NET SDKs without running any other tasks from make. (contributor experience)
  • #3399 (comment). Can we get off of using static state. Perhaps have the instance state computed and passed into the RunAsync method as an appropriate context. Note: inputs/outputs are difficult here as they look at state like IsPreview and don't always have a clear way to determine that value.
  • Use MEF and switch to a plugin model instead of an exe model. This would allow dep-injection to be used by clients and would lead to a more natural way of exposing the user's 'Stack' with attributes intead of with them having a Main method which bounces in and back from Pulumi.
  • Clean things up between Stack and ComponentResource. #3399 (comment)
  • Investigate 'lifting' on .net outputs like we do with JS outputs: #3399 (comment) Related: #3481 (comment)
  • First class unknowns: #3399 (comment)
  • Callback serialization
  • Should we allow arbitrary objects to be exported from a stack? We could convert them to POCOs and export those (like we do with js/ts/python).
  • Attach a debugger to the .NET program
  • what is our SxS story. What are best practices in .NET. Will we need shudder binding redirects? #3450 (comment)
  • Enable running pulumi up on precompiled binaries in case people want to split the compilation from execution #3509
  • F#-idiomatic API
  • PowerShell support #3473 #3507

Parked:

  • namespaces for all the parts of a package resource. i.e. we have Pulumi.Aws, Pulumi.Aws.S3, pulumi.Aws.S3.Inputs, etc. Do we need/want all of these? Is it an acceptable usre experience (both for intellisense and docs)? etc. etc.
  • Should our invokes allow async-inputs, or only sync-values? ts specifies only snyc values. js-impl allows async values. etc. etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can鈥檛 perform that action at this time.