This is another one of those tasks where I thought it should be simple. That should be a red flag right there. I ended up spending way too much time on this, and as it turns out it is really only a matter of syntax. I ran across a lot of incorrect information out there, so I figured I should post this and help make the links to the right content easier to find.
I was actually building my own cmdLet for PowerShell in C#, and decided I should deploy it using PowerShell, which seemed appropriate. For me, the basic stumbling block for getting this working was quotes. I had multiple paths in my script, all of which had spaces in them, which necessitated the use of nested quotes. This was quite hard to figure out, but Philippe had the right information. He also pointed to this article, which had a thorough explanation of how to call PowerShell from the command line, which is essentially what you are doing inside a post-build event.
I have been developing for SharePoint lately, working on timer jobs. This resulted in tons of deployments and job runs, and before I knew it my SharePoint_Config database was huge! I was working in a virtual machine with disk partitions, and my data disk ran out of space. At least it was on a partition and I didn’t hose my OS….
So it seems to be a simple problem to solve. Backup the database, shrink the log file. Not so fast partner, this is SharePoint. The database is not in Simple recovery mode, it’s in Full recovery mode (for a reason I am sure, I just don’t know what it is). You can truncate the log file and remove the data, but the physical file won’t shrink. My colleague J Wolfgang Goerlich pointed out one of his old blog posts that was just the ticket. Essentially you are changing the mode, shrinking the file and changing the mode back all in one operation, which won’t upset SharePoint. The log file went from about 9 gigs to 600k. Nice.
As noted in the blog post, this is not a good thing to do to a production system, there are consequences. But for a dev system I wouldn’t worry about it.
Ever since the var keyword was released in C#, I’ve struggled with using it. To me var felt like using variant or object in VB, even though logically I know it is not.
List<string> items = new List<string>(); vs. var items = new List<string>();
Since I bought Resharper, it’s been nagging me to use var in my declarations, so I have acquiesced. Today that paid off. I had to refactor something which caused a few type changes. It was so much easier to deal with because I used var instead of writing out the declaration the old way, there were just fewer changes. I’m now a complete convert to var, thanks Resharper.