Lets say you have a Model. The name of the model is stored in a string somewhere, and you want to get a reference to do something with that model. How do you do it?
Type.GetType(<string>) is the advertised way, but there are a lot of limitations on that. Primarily assembly location, and FullName versus Name. I ran into this conundrum in a small C# application, and wound up with this solution:
I know this topic has been done to death on StackOverflow, Ninject.Extensions created to solve it, and a million other things. But what if I wanted to use vanilla Ninect in a small solution and didn’t want to use Ninject.Extensions, but still wanted to Bind a bunch of classes at once? I couldn’t find an easy answer, so it’s possible someone else wouldn’t find an easy answer. So here’s an answer using simple reflection. The lazy person in me is going to limit sanitizing code, so pardon the specificity of the variable names, but chances are you’ll need it for the same things.
Creating lists programmatically can be useful in many scenarios. The scenario we run into most often are lists for waterfall projects that aren’t well thought out. Need to define 30 e-mail templates? Forgot a column? Want to easily reset content to a base state? Dealing with these scenarios by deploying list definitions/instances in a package rather than content restores can restore sanity, but does offer some drawbacks. Namely – custom security and content query web parts.
Through various blog posts and contributions by colleagues that I have mostly stolen, butchered, and maybe improved upon, I bring to you a simple Caching utility. DISCLAIMER: The title “Lazy” is meant only for amount of effort, not actual “lazy loading.”
Have you ever needed a more powerful enum? A more user-friendly enum? An enumeration that encompasses a doman-friendly name, a user-friendly name, and a database friendly value? Maybe you need to match a status, error code, of categorization that is strictly defined as a one or two character code that is practically meaningless outside the confines of the organizational brain trust.
I’m sure somebody, somewhere, leverages SharePoint Chrome for displaying the most beautiful and elegant titles on well-designed pages. I, however, am not that person, and have never met that person. The workflow I was accustomed to was:
- Add Web Part to page
- Edit Web Part
- Change Chome to None
- Save & Close Page
- Check In
Something I ran into awhile ago and spent way too long digging out is enabling developer dashboard. “But Lefty, there are thousands of blog posts on this subject, are you dim?” you might ask. Nay, just picky. Most of the time, nobody cares how the admin side of their application performs. Normally if it’s slow, it only affects a few users. And normally those users are either the person or a direct report of the person that contracted the creation of that application. The slow, behemoth that is the admin side helps them further appreciate the nimbleness of the public side. In my experience, the best way to transform that slow behemoth into a nimble speed demon is the developer dashboard, and a liberal application of SPMonitoredScopes.