Update on this SDK

[wadewegner]

As you've no doubt seen, I have not been able to work on this project for awhile. I apologize to all of you who have been impacted by issues that haven't been resolved. Moving forward, I'm committed to actively maintaining this project.

As such, here's my plan. Please feel free to provide feedback:

• I believe one of the reasons we haven't seen much activity is because this repo lives on "developerforce", which has in many ways become a graveyard. I also believe that having this repo on a Salesforce affiliated organization has led some people to think that this SDK is officially supported by Salesforce. It isn't. So, I'll be moving this repo to "WadeWegner" and treating this more like any other open source project.

• As you no doubt have already seen, I've taken the first step towards updating the codebase by moving to .NET Core. Right now I'm targeting .NET Standard 2.0. I'm very open to feedback and what we should support; this seemed like the first best step.

• I will try to put more rigor into getting all the functional and unit tests to work consistently. This was always the hardest part, given my desire to have this SDK work cross platform. With the updates to .NET, it is much easier.

• With the above updates to automation, I want it easier to accept pull requests. I'll also put efforts into guidelines so that when people send PRs they have a better understanding of how to approach making changes, writing tests, and validating their changes.

I'm sure there's probably more but I'll stop now. What else would you like to see?

Thanks, Wade

[robertmclaws]

Hey Wade, great to see this repo is coming back to life! I'd be happy to have my company (@cloudnimble) provide support for this project, whether that be repo space, use of our VSTS for build & deployment, or whatever.

Having used the codebase extensively on other projects, I think there is room to make the system more useful with Salesforce accounts, whether they are customized or not.

• I think it should be possible to remove the service generators and ship the client with core features that are always useful.
• It should have a rich and well-planned out core assembly with intuitive namespaces that has just base models for all the Salesforce API objects (meaning, what fields would be there if you just created an account from scratch and then generated a service?). User, Lead, Opportunity, Contact, Task, etc.
• That core assembly should stand alone and be able to be used as a part of other object models without then dragging other dependencies with it.
• I think it should have ways to access object customizations from the base objects without compiling inherited objects (JSON.NET has ways to dump unmapped attributes into collections and so forth).
• I think it should have query helpers that assist people in doing basic tasks, for example ForceClient.Leads.GetByEmailAsync(string email).
• I think it should have Fluent APIs for helping you report on / get statistical data for records in your Salesforce account. For example:

        /// <summary>
        /// Takes a set of Salesforce results for a given set of dates and summarizes them by fiscal quarter.
        /// </summary>
        /// <param name="client">The <see cref="QueryResult{DateSummary}"/> instance to extend.</param>
        /// <returns>A <see cref="List{QuarterSummery}"/> containing the quarterly summaries for a given Salesforce query.</returns>
        public static List<QuarterSummary> ByQuarter(this QueryResult<DateSummary> queryResult)
        {
            return queryResult.Records
                .GroupBy(c => new { c.ParsedDate.Year, Quarter = c.ParsedDate.GetQuarter() })
                .Select(c => new QuarterSummary() { Year = c.Key.Year, Quarter = c.Key.Quarter, RecordCount = c.Sum(d => d.RecordCount) })
                .OrderBy(c => c.Year)
                .ThenBy(c => c.Quarter)
                .ToList();
        }

I just hit a point in one of our new apps where I have to build Salesforce integration, so I'm happy to help make these things happen. Just let me know. Thanks!

[jayonsoftware]

Thanks, @wadewegner for this, I know you are still a C# guy at heart :-) . I have been using your library as part of the ApexSharp project (https://github.com/apexsharp) .

[johntrenwith]

Hi Wade,

I used this SDK as the foundation when writing my DynamicForce project and was a bit bummed at the time when I found there wasn't an "official" dotnet core version but then very excited to just recently check Scott Hanselman's blog and watch his live-stream port.

So - for suggestions for improvement - the library I wrote was designed to remove some of the leg-work of writing proxy / model classes for Salesforce objects by using the "describe" API call to query an object, e.g.

DescribeObject("/services/data/"+ _connector.ApiVersion + "/sobjects/" + objectName + "/describe/")

and then a C# dynamic type (ExpandoObject) to hold all the fields and their values retrieved on the fly, e.g.

GetObjectQuery(objectName).Result + " WHERE Id = '" + id + "'"; QueryResult<ExpandoObject> results = await _client.QueryAsync<ExpandoObject>(query);

I think this might be a useful thing to have in the core SDK - if it doesn't mess with the cross-platform objective; I don't really know how dynamic typing plays out cross-platform.

It would possibly obviate the need to have base models as @robertmclaws has suggested because these could all be built dynamically - along with any object customisations. It would also make writing query helpers easier:

GetObjectQuery(objectName).Result + " WHERE " + externalIdField + " = '" + externalId + "'";

In this example "externalIdField" and "externalId" hold the name and value respectively so it's a very flexible way to query.

Some food for thought hopefully. Thanks for keeping this SDK going, it's a really valuable bridge between the .NET and Salesforce worlds and I'd be a bit stuck without it!

Cheers,

John

[wadewegner]

@robertmclaws @johntrenwith I really appreciate your ideas and would love to make progress on them with you.

[dcinzona]

Is there a feature / functionality list to be able to ensure parity if a clean rewrite of this SDK is warranted?

[wadewegner]

@dcinzona The plan is not a clean re-write. As you can see, we're working with the existing code and libraries, just updating them so they're modern and work with the latest SDKs and frameworks.

[cal5barton]

@wadewegner, when do you plan on moving the repo to your account? I see there is a fork but it is out of date.

[chris-strauss]

@wadewegner did you end up moving this repo and were you able to convert it to .net core ?

[deesejohn]

After reading this post I decided to write Reinforce, which is an attempted re-write that is dependency injection friendly and leverages RestEase to keep the code base small. I'd appreciate any constructive feedback.