Hi @Justinvolved ,
Ah yes, getting all this modeling done sensibly is a challenge, and documenting it is a whole new pain
The main issue we're facing is that you can't create a Site in IIS without a binding; the API will simply reject it and error. This means that if you use IIS::Ensure-Site to create a site, but don't specify a binding, it will error. However IIS::Ensure-Site can update a site no problem.
This is why we originally created the Bindings property. However, it's a but challenging to use, and exhibits the behavior you describe: it "ensures" that list matches whatever is in the Site.
Our current way of thinking is this:
IIS::Ensure-Site MySite
(
AppPool: MyPool,
Path: C:\Websites\MySite,
BindingProtocol: http,
BindingHostName: app.local,
BindingPort: 80
);
IIS::Ensure-SiteBinding
(
Site: MySite,
Protocol: https,
... ssl properties ...
);
Our "new" way of thinking is that it might make sense to allow IIS::Ensure-Site to have two sets of binding properties.
IIS::Ensure-Site MySite
(
AppPool: MyPool,
Path: C:\Websites\MySite,
HttpHostName: app.local,
HttpBindingPort: 80,
HttpsBindingPort: 443,
HttpsCertificateOrWhatever...
);
This seems to align with how most people want to set up a site in IIS (i.e. two bindings).
Definitely open to your feedback
Cheers,
Alana
