Matthew Cowan

My feedback

  1. 43 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Feature Requests  ·  Flag idea as inappropriate…  ·  Admin →
    Matthew Cowan supported this idea  · 
  2. 84 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Feature Requests  ·  Flag idea as inappropriate…  ·  Admin →
    Matthew Cowan supported this idea  · 
  3. 31 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Feature Requests  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matthew Cowan commented  · 

    A large client of mine is using ServiceStack extensively within their SharePoint environment now, so putting a vote in on this one, as this is already slated to be a paying client.
    The way we have it working is to have the app host intelligently configure itself during application startup. We do this by providing an interface (that's backed by the SharePoint service locator) to the development teams so that they can work with the AppHost at startup (since most things are in the GAC, we don't do auto-discovery, we do discovery based on registered interface classes which we call at startup). While we use a custom service application and database, a regular database could be used, or even just web.config mods. A single feature to install ServiceStack generically for all web applications in the farm on all web front-ends, and then an extension to allow re-use of the ServiceStack infrastructure for new development efforts across product and development teams was key. Most of the actual ServiceStack setup in my experience followed the existing SS documentation for asp.net web forms out-of-the-box. What's awesome, is to be able to call services locally to your web (/<spweb_server_relative_url>/_layouts/api/myservice), keeping context to the SPWeb, which means using SPContext.Current.Web works just fine within the services, and SP authentication requirements can be fully respected natively. The SharePoint story with ServiceStack is AWESOME! I have no experience at the moment yet with SP 2013 and ServiceStack, but I'm sure more can be done there too. Almost every dev I've worked with that started working with the ServiceStack implementation within SharePoint raves about it's simplicity over the WCF alternative, especially the ease of registering a new service into their dev VM and incorporating services into their web parts and layout pages, etc... (click, deploy, done! :-) ).

    Matthew Cowan supported this idea  · 
  4. 15 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Feature Requests  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Matthew Cowan commented  · 

    Sounds good. Initially I thought I would be able to contribute to the code base in this area, but I haven't come up with something yet that I feel is applicable enough to the larger community, without introducing assumptions that mostly don't belong in the framework, I'm too buried perhaps in my use-cases. I think if more people get interested in visiting this feature set, or related features, we'd get better consensus on specific desired outcomes.

    If an injectable strategy can be introduced, that would suit me just fine, better than fine even. I'll be glad to visit it with you if the window of opportunity arises, and anyone else if there's interest.

    Matthew Cowan shared this idea  · 

Feedback and Knowledge Base