Today I was developing a custom forms based authentication provider against CRM 3.0 when I got three exceptions that led to an interesting outcome.
OS: Windows 2003 Enterprise Edition x64
IDE: Visual Studio 2008 RTM
Configuration: Default Zone (http://toronto1) with NTLM, Internet Zone (http://toronto1:26415) with FBA
Debugging Mode : Locally
Exception1: System.Threading.ThreadAbortException.
Exception2: Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.
Exception3: Mixed mode debugging is not supported on Windows 64-bit platforms .
Before I get into how I got the exceptions, let me elaborate a bit on how I was led to all this. After developing the authentication provider, I created a log in web part that authenticates the users against CRM database (using my custom auth provider) and add them to the Visitors group upon thier successful login plus some other custom actions which is beyond the scope of this post. Read more…
If like me, you also have the tendency to forget (*not that I wish for it*) the version numbers before and after SP1 is applied, here is a little visual help for all of us.
- Original release version of Windows SharePoint Services 3.0 is 12.0.0.4518. This applies to both WSS and MOSS installations – Remember, MOSS is built on the top of WSS.
- Updated version of Windows SharePoint Services 3.0 after SP1 is installed is 12.0.0.6219.
If you are going to install a clean WSS from the scratch either on 2003 or 2008, I would highly suggest you to go for WSS with SP1 Slipstream. It can be downloaded for both 32 bit and 64 bits.Update: You’ll see slipstream bits for MOSS SP1 in the next few weeks.
Update (9/March/2008): Wait for MOSS 2007 SP1 slipstream is finally over , see Joel Olson’s post at http://blogs.msdn.com/sharepoint/archive/2008/03/07/moss-2007-with-sp1-slipstream-officeserverwithsp1-exe-released.aspx
Update (07/August/2008): Applying Infrastructure roll up? Here is the new version – https://blogs.devhorizon.com/reza/?p=593
Configuration API introduced in .NET 2.0 gave us whole bunch of options to read and update configuration files such web.config and machine.config files. A very useful framework if you want to dynamically interact with configuration files as they apply to your web applications. WebConfigurationManager possesses all the knowledge of the web.config object model and provides full access to it. The Question is : Can I use this API to access and change web.config files associated with my SharePoint apps? Yes , you certainly can, but you have to keep track of the changes , support the ability to roll them back and more importantly in a farm installation where your app is scaled across multiple web front end servers , your code should be able to reach out to those servers and apply changes (Add/Delete/Update). Although it is not impossible to do it this way, it’s simply more convenient if WSS Object Model could take care of this for us.
Conveniently, WSS object model offers a new class this time around which allows your code (that is within your Feature event receivers , console apps or custom installation applications) to dynamically make and propagate changes to web.config files across your farm using SPWebConfigModification class (Microsoft.SharePoint.Administration namespace). You have the option to add/modify/delete sections, child elements and attributes with some limitations and through many workarounds! We will take a look at some of the issues and workarounds (if there is any:)) in this post. Read more…
