I’ve been resuming my collaboration on MSDN SharePoint forums lately, so that’s why I’ve been slow to update the blog these days.
I answer questions on MSDN SharePoint Development Forum, General Forum and Spanish-language Development Forum. You can check my threads here.
I can only hope that my answers help shed some light on everyday SharePoint issues. It’s a pleasure to be able to help.
They are based on the Tech-Ed Visual Studio demonstration video. In one moment the presenter opens a SharePoint portal but it’s 2010 pre-beta version, according to the look & feel. Usually Microsoft keeps the same UI as the previous version before the public beta.
Basically, it’s a MOSS 2007 look with a red “Give Feedback” button and sexy AJAX inline list editing, skipping the edit forms and datasheet control. Cool!
More details at Lee Richardon’s site.
Today I had a strange error happening trying to deploy a WSP package on a SharePoint farm that had 2 front-end servers. On my local development virtual machine it deployed and activated flawlessly, but on the farm it deployed itself only to the local server and not the other server, stating that the deployment failed.
It also gave the following misleading log entry in SharePoint logs:
OWSTIMER.EXE (0x065C) Windows SharePoint Services Timer
The Execute method of job definition "SPSolutionDeploymentJobDefinition" (id "0943ea83-88d3-4eae-b2d0-21ffca1c66ec") threw an exception. The method or operation is not implemented.
I double-checked the class name, the receiver assembly name. I removed all traces of the package (FEATURE files, DLL in the GAC), I did countless IISRESETs…in vain. The error repeated itself back and back again.
I had a moment of inspiration and I restarted the WSS Timer Service on both front-end servers. I tried to deploy the solution again. It worked perfectly this time!
Five hours lost to a deadlocked OWSTIMER.EXE thread 🙁
Welcome to a new post of “My Adventures in SIlverlight” series. In this post I’ll try to outline a few caveats I found while trying to communicate a Silverlight ciient application and a WCF provider service.
As we mentioned earlier, Silverlight only recognizes basicHttpBinding protocol. It means that it cannot use web service extensions for authentication, unlike standard ASP.NET applications. Furthermore, as Silverlight is a platform-agnostic technology, it cannot use Windows authentication neither. In an enterprise environment, this is a serious handicap.
You can use a non-authenticated service as a endpoint for a Silverlight client to connect to. Inside the method call, insert the username and a secret value only known to both the client application and the server. This secret value should act as a second check (the first is the username) for the service.
It’s not flawless, thought, but it should be considered.
If your Silverlight application runs in the same IIS site as the service it’s trying to consume, and this requires authentication, then you can forfeit the authentication code. Silverlight can consume a secured web service without authentication as long as the service and Silverlight client application are in the same IIS site.
