BBCRM SDK – Visual Studio and Developer Environment

If you’re starting out customizing BBCRM, or even if you’ve been doing so for several years, it’s not unusual to run into frustrations that you feel should be solvable, but that you can’t find a ready answer for among the excellent BBCRM customization resources already out there.  If you’re not already aware, the website provides a great technical reference along with a reasonably well-trafficked Q&A site.  Even so, sometimes it’s hard to find the answer you’re looking for.

This blog introduces a series of posts with practical advice and guidance based on real-world customization development and several years of questions from BBCRM SDK trainings I’ve conducted.  Please feel free to contact me if I can clarify or explain any of this–or if you’ve found alternative ways to address the topic.


SDK Download

  • You can download the BB CRM SDK from Blackbaud’s website under “Support->Downloads”, “Blackbaud Infinity SDK”.

Creating Catalog/UI Model Projects

My approach does NOT use the built-in “AppFx Solution” (see below) because I prefer to configure my build output paths and other Visual Studio project settings in a different way.


In particular, I want to use the standard “Build output path” values (“bin\debug” and “bin\release”) for the following reasons:

  • Different users working on the solution might have a different directory structure.  For teams of developers, ideally all developers will have the same folder structure, but this isn’t always the case.
  • Automated build/deploy environments and processes are much easier to create when the standard output paths are used.


Having said all of that, here is my personally preferred way to set up catalog and UI model projects as part of a solution:

  • First I create a new “Blank Solution” project, for example:

  • After catalog and/or UI model projects, check the “Output path” for the project by right-clicking the project, viewing “Properties”, selecting the “Compile” tab, and checking the “Build output path”:

  • If you see build warning related to referenced rulesets not being found:
    • Expand the “Managed Binary Analysis”, set the “Project” to “<All>” on the drop-down, and disable the items starting with “BB”:


Naming Conventions

  • A blog post with advice on naming your solutions, projects, and customization files is here:
  • When assigning a name to the “Name” attribute on a spec’s root-level element, prefix or postfix the name with something to ensure it is unique—e.g. a table spec with the name “Sports Event” might be renamed “Custom Sports Event” or “Sports Event (Custom)”. This ensures the name stays unique even if Blackbaud releases a product feature somewhere down the line that has the name “Sports Event”.
    • This does NOT apply to task specs, which allow having multiple task specs with the same “Name” attribute.

Load Spec

  • By default, the “Load Spec” external tool in Visual Studio does not set the “/forcereload” flag that causes LoadSpec.exe to reload a spec even if it apparently hasn’t changed since the last load. Sometimes you want a spec to reload even if it doesn’t seem to have changed (e.g. to re-run “Alter Existing Pages” rules), so it’s usually a good idea to update the flags provided to “Load Spec” by doing the following:
    • In Visual Studio, go to “Tools -> External tools…” and find “Load Spec”:
    • Ensure the flag “/forcereload” is on the end of the arguments list.

Unload Spec

  • The “Unload Spec” tool in the Visual Studio “Tools” menu can be useful for unloading a spec that won’t reload due to some change you’ve made in the spec. For example, table specs don’t support renaming the table and SP data form specs don’t support renaming the underlying stored procedure.  In these cases, “Unload Spec” can back the spec out, allowing you to reload the altered spec.
    • This tool is NOT recommended for production environments—only use “Unload Spec” in developer environments.

Share this post