A few weeks ago I wrote a post about how to access the PSI methods via the PSContext object, that represent the Project Server context in the server side object model. As I wrote in the side note in my post, there are some issues with this object. In the current post I explain what I mean on that exactly. The content of the post relates to the 2016 May CU of Project Server, older and newer CUs might behave differently.
The PSContext class has no public constructor. There are however three overloads of the static GetContext method you can use to get the context: one with an SPSite parameter, one with an SPWeb parameter, and one with a Uri parameter. These methods call the corresponding private constructors (one with an SPSite parameter, one with an SPWeb parameter, and one with a Uri parameter either) of the PSContext class. The private constructor having a Uri parameter creates an SPSite instance based on the Uri and then calls the constructor having an SPSite parameter. The constructor having an SPSite parameter takes the root web of the SPSite instance, and calls the constructor having the SPWeb parameter.
A potential issue I found is, that the PSContext constructor with the SPSite parameter type stores the SPSite parameter in a private field and dispose it when the PSContext object gets disposed. Although I have not yet faced with its side effects, you should be aware of this behavior to avoid surprises.
I think the site should be stored in the private field and be disposed in the case of the PSContext constructor with the Uri parameter type (as we create a new SPSite instance in this case), and not in the constructor with the SPSite parameter when we get the SPSite instance from the external code.
But a more serious issue that caused me some headache already is the next one:
In my recent post I described, that the private static RetrieveValue method of the PJClientCallableContext class (that is an important part of the context construction) behaves differently based on the condition, whether or not the process runs with or without a HTTP context. Without HTTP context, the SPWeb object passed to the PSContext constructor is used to create the context. Otherwise, if we have an HTTP context, the SPWeb object (or the Uri, or the SPSite, depending on which constructor you invoked) passed to the PSContext constructor is simply ignored. Let’s see what it means for the developers.
As long as you use the PSContext object from a console application, or from an application without an HTTP context, like a timer job or Windows service, it’s OK, as far as I see. You might be however surprised if you think the parameters of the GetContext methods have any significance if the PSContext object is used in a web application. Based on my experience they do not have any. Of course, the value of the Uri parameter, if you use this overload, should point to a SharePoint site, to enable the creation of the SPSite instance. But beyond that, the parameter is simply ignored.
If the web page belongs to a PWA instance, then this PWA instance will be used as the context.
If you happen to have multiple PWA instances on the same server, you can not access the other one via the PSContext object, even if you pass a parameter (Uri, SPSite or SPWeb) to the GetContext method that points to the other PWA instance.
You can even pass a parameter (Uri, SPSite or SPWeb) to the GetContext method that points to a SharePoint site without PWA instance, still the PWA instance of the page will be used.
It means on the other side, that you can not use the PSContext object in a web page without PWA instance (at least, unless you try to fake the HTTP context as described here). If you try it, you receive an HTTP 403 error (similar to the error discussed in this post):
A first chance exception of type ‘System.UnauthorizedAccessException’ occurred in mscorlib.dll
Additional information: Attempted to perform an unauthorized operation.
at Microsoft.ProjectServer.PJClientCallable.CallPSITag[TResult](UInt32 ulsID, String caller, Func`2 body, Action`2 onError)
at System.Linq.Enumerable.Count[TSource](IEnumerable`1 source)
at Custom.YourTest.Page_Load(Object sender, EventArgs e)
I think a better implementation of the PSContext object would be to have a static Current getter property (similar to the SPContext class) that we could use only if there is a HTTP context, otherwise it would return null or throw an Exception. The static GetContext method should have been reserved for usage from processes without HTTP context. Invoking these methods from a process having HTTP context should throw an exception.