VS 2010 Performance Improvement

I was working on testing some bugs out on my BizTalk 2010 beta computer and encountered a popup in VS 2010 advertising that it would run faster with the addition of a certain patch for the Windows Automation API. I usually skip these on a test VM but sometimes VS 2010 does run pretty slow when you only allocate 1.5 GB for the whole VM. 🙂 So I clicked on it and downloaded it and was surprised that VS 2010 does run a lot faster even on only 1.5 GB of RAM.
 
This hotfix does not mention VS 2010 at all in the description: http://support.microsoft.com/kb/971513. This hotfix was created prior to VS 2010 RC so I guess it was suggested as a fix when the RC intellisense issues came up. I was using VS 2010 RTM Premium. This blog post mentions that the fix was already forward applied to VS 2010 RTM (http://blogs.msdn.com/b/visualstudio/archive/2010/03/02/second-patch-now-available-for-intellisense-crashes-in-vs-2010-rc.aspx), but this was not the case for me. I was not exactly encountering blocking performance, it just took a long time for VS 2010 to load and do things. I did not initiate the popup – it just appeared and I followed it so I am guessing this functionality to advertise the hotfix was a backup plan in case the VS 2010 RTM fix failed. Here is the Connect link for the original performance issue for anyone interested: https://connect.microsoft.com/VisualStudio/feedback/details/532783/very-slow-intellisense?wa=wsignin1.0.
 
Anyway, I recommend applying this hotfix for faster VS performance. Interestingly, this hotfix comes in a different download for XP – http://www.microsoft.com/downloads/details.aspx?FamilyId=cd55456d-9703-42a0-b982-8a8a89ca0aa3&displaylang=en. This may even improve VS performance for previous VS versions before 2010.
 
Thanks,

WCF the REST way

Today I attended a session on using WCF through the REST model of web service interactions. This remote method model is based on HTTP requests and includes the following HTTP actions: GET, POST, PUT, and DELETE. This model relies more heavily on the role of URIs as a way to more clearly define resource endpoints. Jon Flanders talked about techniques in defining well-known URLs based on the general experience most people have with the web and URLs. Resources in the REST model are useful because they more clearly identify entities within a business object model. So rather than have a service method called GetWidgets you would have a Widgets resource and send in a GET action to get the Widgets.
 
Recently, I have been reading through the book Learning WCF (by that Indigo girl) and it spends some time explaining the role of endpoint base addresses and full addresses. Base addresses are based on a configuration entry for the address and then a Service URI that indicates the service at which the base address then exists. Here is a link about the use of Base Address: http://www.dasblonde.net/CommentView,guid,756f2aee-7146-4bc3-8406-d0e3530dc507.aspx (the CSS styling is not working right on her site so select the text on the article to see the text.) I did not hear much in the REST session about the role of base addresses and full addresses, but it seems like this would be a more natural approach than building an extra long url like a Flickr url (http://www.flickr.com/photos/mzalikowski/530036109/) where the date is a meaningful URI and one of a couple different resource addresses possible with Flickr.
 
I think the REST model will serve to simplify the addressing schemes used with web services but I am a little worried about interoperability. For example, if a SOAP service exposes a web service endpoint that provides WSDL, it would also make sense to expose an endpoint that provides REST since it is a different invocation standard. WSDL has very widespread adoption, whereas REST is not implemented by everyone and could take a while before all vendors provide a compatible implementation. I am worried about web service integration that does not recognize PUT or DELETE operations and the possibility that these may be handled inproperly if a SOAP engine or HTTP engine processes these incorrectly. More to follow on whether I find any incompatibilities or gotchas with REST…
 
Tune in tomorrow for a post on the last day of TechEd. Thanks to anyone who has been reading my posts.

LINQ to SharePoint and PopFly

I was thinking about how painful it is to create SharePoint queries using CAML and then realized that Linq would be an excellent tool to handle this. I found the LINQ to SharePoint project on Codeplex and realized someone had already built this capability. It looks like this product vastly helps reduce the complexity of doing a CAML query. Coupled with the ADO.NET Entity framework I think the possibilities for managing the SharePoint data access layer are getting easier and easier. One question to ask would be where within an n-tier infrastructure would LINQ queries be best placed. Obviously LINQ queries can function a lot like database queries but they can also act like a middle-tier business rules layer. If LINQ is coupled with a tradition O/R abstraction layer, LINQ can co-exist with O/R or even make it more efficient.
 
Another thing I thought of recently was whether PopFly can handle LINQ queries. Although mashups can be effectively chained together it would be very interesting if the results from one mashup could be queries through a LINQ query. If time permits I will be trying to use LINQ within a PopFly project developed in Visual Studio to see if a block can interrogate another block’s data using LINQ.

Blog at WordPress.com.

Up ↑