Move infrastructure classes to a separate assembly

Topics: Developer Forum
Jan 10, 2007 at 12:00 AM
What do you think about moving the infrastructure classes into a separate Pscx.Infrastructure assembly? That would allow people to use our base classes and utilities in their own snapins and libraries.
Jan 10, 2007 at 4:09 AM
As along as we can easily tease out the core stuff into a separate assembly. Is this something that we want to try to do now or after the 1.1 release (early February)? Also how about we use the shorter name Pscx.Core.dll?
Jan 10, 2007 at 1:20 PM
ok, Pscx.Core is better
Jan 10, 2007 at 2:58 PM
i think we can move it right now, if we keep the namespace
Jan 10, 2007 at 4:51 PM
i think that's a good idea -- I'm working also on a set of base classes for navigable providers; they are fully generic and I'm using a flavour of them already for my SharePoint provider (codeplex: PSSharePoint). When I get the first round of fixes into it, I will "pscx" them and there might be time to pop them into the core for 1.1, if not, definitely 1.2.

- Oisin
Jan 11, 2007 at 5:05 PM
YOU ARE KEEEPING A SHARE POINT PROVIDER FOR YOURSELF?????!!!! :-))) that would make a great addition to Pscx!

I've split the assembly in my workspace. May I check it in?
Jan 11, 2007 at 6:40 PM
haha, nah, it's not ready yet man -- I'm still actively enhancing it (and isolating the basestoreprovider bits). I'd rather it wasn't forked yet.

Additionally, there is the slight problem of the Microsoft.SharePoint.dll compile time dependency. This DLL cannot be redistributed with our pscx project. I have a solution in place whereby the local object model assembly which has the dependency is stored as a binary resource and read in dynamically if required (and sharepoint is detected).

Anyhow, the intention is to provide the BaseStoreProvider code in Pscx.Core and have our other providers built from this. I'd rather keep the sharepoint project separate for the moment.

- Oisin
Jan 11, 2007 at 7:51 PM
I was going to say that I'm OK with checking in the split but if Oisin not ready, well then, he's not ready. :-)
Jan 12, 2007 at 11:58 AM
Keith, I believe Oisin was talking about his SP provider, not about the split. I am going to check it in.

Oisin, I dont think the Microsoft.SharePoint dependency would be a problem. We already have a dependency on team foundation client assemblies (which we are not allowed to redistribute, just as we are not allowed to redistribute power shell assemblies)
Jan 12, 2007 at 5:25 PM
we have a dependency on TF assemblies? argh.. isn't that bad? Where do people get those from? Is that the 250MB+ turd that we have to install for codeplex? If so, doesn't this mean that PSCX implicitly requires visual studio 2005 to be installed ?

Please say it isn't so.
Jan 12, 2007 at 10:14 PM
You don't need TF installed to install or run PSCX. If you want to run the TF specific cmdlets then obviously you need the TF client installed. However, if you just want to download source and build it, then you need the TF assemblies in order to compile. I would like to get permission from Micrsoft to include 4 TF assemblies in our Imports folder but not install those 4 assemblies. It is also entirely possible that I might shelve the TF cmdlets and release them in a post 1.1 release.