Hello world! Last time (year or so) I was busy on anything else but my module. Now I’m happy to announce that the project isn’t died, it is alive and new version is published.
This version doesn’t bring new commands, nor deprecate any. I think, command list is well-established and I don’t see anything useful to add. People doesn’t ask either. However there are things to work with code: refactor, optimize, make it cleaner and so on. Let’s look at what I’ve done here:
Initially, project was hosted at CodePlex which is died now. I moved all my sources to GitHub, documentation to my web site and used CodePlex as module download place.
Since CodePlex is done, the only real option to ship binaries was to use PowerShell Gallery. It is something new to me (I never used it till today) and was a bit lost there. But it appeared more easier than I thought. Starting with v3.2.7, the module is available on PowerShell Gallery: PSPKI. Please, provide feedback on your experience with getting PowerShell PKI module from gallery.
In the past, I used MSI installer to ship the module. It is still very good option to do that, because you can use various tools, like group policies or ConfigMgr to deploy the module within organization. Thanks to Caphyon Advanced Installer and their free NFR license (as a part of my Microsoft MVP award) I was able to do that. And their tool was really great and easy to use. However, my MVP award options are uncertain and PowerShell Gallery is an acceptable tradeoff, so there is no big need in MSI anymore.
I’m working on:
When I initially developed these commands I simply mapped CA database columns as properties in output object:
RequestID : 1944 Request.RequesterName : CONTOSO\Administrator
And some columns have dots in names. As the result, you cannot easily access these properties, e.g.
$row.Request.RequesterName. PowerShell don’t expect
Request.RequesterName as a single property. Instead, it expects a property called
Request and another property (in underlying object) with
RequesterName name. In order to access this property you have to do ugly things like
$row."Request.RequesterName". I didn’t bother myself with quick fix (simply replace dots with underline character) and lost time. Now I can’t simply change it, because too many scripts will be broken. Currently I see two options for this:
$row.Properties["Request_RequesterName]". Similarly like you access AD properties in ADSI objects.
I haven’t decided which one to use and would like to hear your opinions as well.
I’m struggling with:
I’m trying to develop universal generic ASN.1 tree/tree node class to easily traverse ASN nodes and consume it everywhere with an ability to extend it via interfaces. This is blocking issue for me, as I can’t move forward with ASN.1 Editor and PKI.Core.dll library.
PKI.Core.dll is main underlying library I wrote to support PSPKI functionality. The library is relatively large, there are tons of classes and they are used even outside of PSPKI module. The problem is with authoring and bad design. When I started this project I didn’t follow conventions/guidelines and selected wrong namespaces. For example, I added a lot of stuff in System.Security.Cryptography namespace which belongs to Microsoft. As more I learn as more difficult issues I face in design. I may need to change, but this will lead to total mess for module/library users, who will be forced to rewrite a lot of code to fix these namespaces. I don’t see any other option except to abandon everything and start from scratch. Make something like “reload”. This is very hard decision and I have no idea how to deal with these huge design mistakes I made in the past. If you have ideas, suggestions how to solve these design issues, do not hesitate to reach me.
Where to get the module now?
Post your comment: