Some feedback from when I demonstrate pulumi .net support to .net people - "why can't I just run my program?". The initial impressions are that requiring pulumi CLI to run the IaC instead of the standard

dotnet run

is "non-standard" and "against the grain". The expectation is that the .net program should be spawning the pulumi "engine" and not the other way around. And to be honest, I can see their point. There was also a couple of other comments • "I want to do other things in my program as part of deployment such as a db migration." • "I want to use this to define resources of my own services" This got me thinking a bit that it inverts things and turns pulumi into more of a platform and a bit more into orchestration which is bit of a fundamental architectural shift, afaik. Anyway, just thought it would be interesting to share.

Hi Damian. Thanks for the feedback! > The expectation is that the .net program should be spawning the pulumi "engine" and not the other way around. There are several things to discuss here - would you mind opening an issue so that we could go in more depth? > I want to do other things in my program as part of deployment such as a db migration Likely, this should be another resource in Pulumi model. Are you familar with the concept of dynamic providers (not yet supported for .NET)? > I want to use this to define resources of my own services Similar to the last point, this should be a Pulumi provider then.