Salesforce.com is attempting to make it easier for .NET developers to consume its web services thanks to a new pair of open-source Toolkits. These Toolkits target the Force.com REST API and Chatter API and are the brainchild of Salesforce Platform Advocate Wade Wegner who talked to InfoQ about the goals and logistics of building these components.
The Salesforce.com platform has over 1.4 million developers and provides a broad API available through SOAP and REST endpoints. The company offers simpler API access via SDKs for JavaScript, PHP, and mobile (iOS and Android) developers. While the company maintains a dedicated resource site for .NET developers, those developers have had no libraries to accelerate development. Until now. The new Force.com Toolkits for .NET – with source code and samples hosted on GitHub – includes native libraries that run on multiple Microsoft platforms including Windows 8, Windows Phone 8, and Silverlight 5.
InfoQ reached out to Wegner to learn more about this Toolkit and what it takes to build and distribute an SDK to developers.
InfoQ: You’ve just released a set of toolkits for .NET developers. What exactly do these toolkits provide and how do you get them?
Wegner: The Salesforce1 platform provides powerful developer APIs that makes building applications simple, powerful, and secure. To provide a great experience for .NET developers we havereleased to open source the Force.com Toolkit for .NET and the Chatter Toolkit for .NET. With these toolkits it is now incredibly easy for .NET developers to use these APIs using the skills and tools they are already familiar using today. By simply consuming these resources through published NuGet packages, .NET developers can easily build new applications powered by the Salesforce1 platform and add Salesforce1 platform capabilities into existing applications.
The toolkits are comprised of the following resources:
- A set of native libraries for the Microsoft .NET Framework.
- NuGet packages for easy deployment and versioning.
- Sample applications to get you started.
You can find all the source code in Github:
https://github.com/developerforce/Force.com-Toolkit-for-NET
https://github.com/developerforce/Chatter-Toolkit-for-NET
https://github.com/developerforce/Common-Libraries-for-NET
The NuGet packages are published here:
http://www.nuget.org/packages/DeveloperForce.Force/
InfoQ: Microsoft and Salesforce aren't known to have the coziest relationship. What demand did you see that led to this toolkit?
Wegner: We have a lot of joint customers, and our number one priority is making them all successful. Based on our development survey data we know that .NET developers are one of the largest constituents of our developer ecosystem. By making .NET developers more productive and able to connect to customer information and systems in Salesforce1, we believe we can help them deliver value to their business and their customers faster.
InfoQ: What were your guiding principles when designing this toolkit, and what should any developer think about when preparing a resource like this?
Wegner: There were a few key design principles we followed when designing and building these toolkits.
- Provide support for as many modern Microsoft platforms as possible with the same core library. To accomplish this, the toolkits makes use of Portable Class Libraries to enable use on the following platforms: Windows 7 (.NET 4, .NET 4.5), Windows 8, Windows Phone 8, and Silverlight 5.
- Avoid performance bottlenecks and application blocking. To accomplish this, the toolkits make use of the Async and Await pattern for asynchronous programming.
- Allow developers to take advantage of dynamic objects so that they don’t necessarily have to create classes to represent every Salesforce1 object.
- Provide the support for key operations and enable the community participate in active development of the toolkits. You will see that our policy for contributions is extremely permissive – we want you to participate!
- Use NuGet packages as the primary delivery mechanism while allowing access to the underlying source code. Furthermore, give developer’s access to the latest development/test packages.
When building your own resources for developers I encourage you to think about these principles.
We feel these principles have set us up for success. Already we’ve seen many code contributions from the community through Github pull requests, significant usage of the NuGet packages, and lots of excitement through blog posts and apps built.
InfoQ: Explain to us the pipeline you created from source control all the way to distribution of the toolkit.
Wegner: I’m glad you asked. I’m pleased with how we’ve put all this together. It all starts with our repositories on Github. We have three:
https://github.com/developerforce/Force.com-Toolkit-for-NET
https://github.com/developerforce/Chatter-Toolkit-for-NET
https://github.com/developerforce/Common-Libraries-for-NET
For each repository we use the Fork & Pull development model. This makes it very easy for us to collaborate - both internally and externally - on the toolkits.
In each of the repositories you’ll see a similar folder structure:
/nugets
/samples
/src
/<ProjectName>
/<ProjectName>.FunctionalTests
/<ProjectName>.UnitTests
The /nugets folder includes all the files used to create our published NuGet packages. We can easily run package.bat <version> to create a NuGet package based on the Nuspec file and then publish directly to NuGet Gallery. Relationships are maintained between the various projects by including references to the published NuGet packages. This makes it easy for developers to manage the dependencies and versions, even after they’ve started using them within their own projects.
The /samples folder includes sample applications for the respective toolkit. You’ll find samples for Windows Phone 8, Windows 8. and traditional .NET 4 and 4.5 applications.
The /src folder contains all the source for the toolkits, including functional tests and unit tests. The functional tests are tests that communicate to the Salesforce1 APIs directly and ensure our code is healthy. The unit tests are test that largely mock the various HTTP calls and ensure we’re creating our requests and handling responses appropriately.
Anytime we make a commit to the repository it kicks off a build on our TeamCity build server we run in the cloud. We have a set of “Debug CI Build” templates that the following build tasks:
- Check and make sure the solutions compile. This includes that sample applications.
- Run all of our functional tests using a real Salesforce1 Developer Edition organization.
- Run all of our unit tests.
- Create and publish a “latest development version” NuGet build to our build server, which also functions as a private NuGet gallery.
All this is done to help us ensure we never break the toolkits. If anything fails two things occur: 1) emails are sent to repository admins, and 2) the little graphic in our repository README.md file turns from green to red.
These steps have made it very easy for us to continue to evolve and enhance the toolkits - especially when accepting pull requests from members of the developer community!
InfoQ: Now that you've completed this initial release, what advice do you have for others when choosing how to build/license/deploy a toolkit like this?
Wegner: The #1 piece of advice I can give is to find a great group of people to support and provide feedback throughout the process. I was lucky to pull together a great group of experts in the .NET and Salesforce1 platform communities, and regularly sought out their advice.