Posts Tagged ‘.NET Development’Public proxied access to SharePoint (WSS or MOSS)Wednesday, April 30th, 2008We use Microsoft Office SharePoint 2007 internally to manage all kinds of work and share documents. It’s a very effective tool. We also use it to manage our software registration database. To facilitate customer software registrations we have a public-facing web service that uses SharePoint APIs to communicate with our registration site. The configuration of SharePoint required some fiddling to make this work. The problem was that we had SharePoint configured with no anonymous access, and obviously the users of our software that would be registering would not have credentials for our network – we didn’t really want to enable anonymous access so a creative solution was required. In order to achieve this we used the web.config <identity /> element in our public-facing website to set the identity of the thread to a fixed user account created just for the task. The web service application pool is configured in IIS to run as “Network Service”. The SharePoint API seemed to pick up the user from the HttpContext.Current.User object, rather than from the thread which means that all our communications were failing with 401.5 errors. I was a little surprised to discover that despite the <identity userName=“user” password=“pass” impersonate=“true” /> in the web.config file, the HttpContext.Current.User was still anonymous. The two tricks that made it work were:
The Global.asax trick ensures that the context carries the same user account as the impersonated thread. The AllowUnsafeUpdates is required when impersonating.
Forms, Controls & the Forms DesignerMonday, April 14th, 2008I was just working on a Windows app that contains lots and lots of User Controls all of which inherit from a base User Control. When I opened the controls they displayed blank in the designer. After some digging I realised that two vital pieces were missing:
It seems the Forms Designer creates an instance of the control by calling the parameterless constructor (which seems obvious when you think about it I suppose). The giveaway on the InitializeComponent() call was the comment just above the call injected by default which reads “Required for Windows Form Designer support“. Anyways – hopefully this will save somebody some time.
VS.NET2003, Windows Vista & Remote DebuggingThursday, March 22nd, 2007If you’re like me you will have a development machine that’s got a bit of power behind it. You might also be a bit keen on new technology. You may have even gone ahead and installed Windows Vista thinking – she’ll be right. If you’re still like me at this point you’ll be thinking “bugger”. Visual Studio.NET 2003 is not supported on Vista = but it does work for the most part. The big issue is web development. What has worked for me, and may well work for you, is installing Windows XP on Virtual PC 2007 (free). I put my web sites on the XP VPC and I can still run the IDE on Vista. While this is a little clunky everything seems to work pretty well. Then one day… bang! The debugger refused to attach. Checking the event logs I found a very unhelpful Event ID 10023: “The application-specific access security descriptor for the COM Server application C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe is invalid. It contains Access Control Entries with permissions that are invalid. The requested action was therefore not performed. The application set this security permission programmatically; to modify this security permission contact the application vendor.” I have no idea what happened from one minute to the next but it was properly busted. I tried a million things including every known remote debugging setup check. I even reinstalled VS.NET 2003 & VS2005. The thing that eventually did the trick was:
I suspect there was another issue, and in trying to solve it I had added domain accounts to the DCOM config of Machine Debug Manager in “Access Permissions”. Further testing has revealed that this is what has killed it. If you are having this problem now you know why
Debugging TipsWednesday, February 28th, 2007The number one problem I find when I help someone debug a problem is the assumptions that have been made. If you’re running a program and it doesn’t behave the way you expect it to what are you going to do? “Step through the code to see what’s going wrong” you say? Chances are that will only help you if you’ve done something obvious, like a typo or a missing bracket. Besides which there are lots of times when stepping through code is impractical or just not possible, such as when the problem is in a CSS style expression. Debugging these is a downright pain. The first thing you should do after the obvious leads are exhausted is to CHALLENGE YOUR ASSUMPTIONS! (Yes I’m shouting it.) I can’t stress this enough – back to the aforementioned CSS style, what kind of assumptions have we made:
Simple questions to answer but do ask them. A lot of the time you’ll notice that you aren’t where you think you are – which explains why you’re going the wrong way. Get used to using Debug.Assert()If you don’t use this gem of a method you’re only slowing yourself down. This comes right back to challenging your assumptions. The Assert() method allows you to add a test expression and a message into your code – when the test fails the message is displayed. The beautiful thing is you can leave them all over the place, because when you compile for Release the compiler leaves them all out. You should include one of these whenever you make an assumption in code – because we can’t always remember our own rules, and sometimes we’re not the only ones using our code. For example, I recently had a problem with a form’s progress meter not displaying properly – I never got any value from it. I added a Debug.Asset() to check the value of pb.Maximum – surely the maximum value was not set to 0 – it should be the record count from a record set I had just loaded. Oh no… turns out the call to set the maximum and the call to load the records were in the wrong order. The Assert pulled me right up. This gets even better when you’re programming in a multi-threaded environment, because the act of debugging interferes with the way the threads behave, since you artificially slow down the execution. Debugger.Launch() & Debugger.Break()Two more little gems, these. Quite often people ask on news groups and the like “how do I debug a Windows Process”? EASY! In your Start() method simply add: Debugger.Launch(); Debugger.Break(); When the run-time hits the first line it will pause processing and prompt you to attach a debugger. The second line is a programmatic break point (which you don’t officially need but the Launch() breaks you into the Dissassembler instead of the code). If you’re a web programmer you may already know about… Javascript: debuggerThis works the same way as Debugger.Launch() but for Javascript – perfect for debugging web pages! It is a statement, not a method, so to use it simply put in the line: debugger; and you’re done.
|
ArchivesTag Cloud |
For some reason simply removing the offending accounts doesn’t help you have to perform the steps above.