Vale a leitura: uma lista dos 46 melhores utilitários freeware. Destaque para os melhores:
· Antivirus (AVG, Avast! e AOL Anti Virus Shield)
· Firewall (Kerio Personal Firewall)
· Zip utility (7-Zip)
· FTP Client (FileZilla)
Para a lista completa e outras opções em cada categoria, visite o site original.
Feed: Aggregated Feed: SharePoint Team Blogs
Posted on: Tuesday, April 10, 2007 9:02 AM
Author: sptblog
Subject: Debugger "Feature" for SharePoint
| While Windows SharePoint Services 3.0 provides an excellent platform for developing Web applications, debugging them can be a bit of a pain. It's often a case of finding the process ID (PID), attach the debugger, navigate to the error, rinse, and repeat, but programmers love to write code, not navigate through menus. J Fortunately, my good ol' buddy from Microsoft Consulting Services and developer extraordinaire, Jonathan Dibble, created a nifty "Debugger Feature" that can be installed and activated on a SharePoint site to make the debugging experience much easier to initiate. Jonathan is a brilliant guy, but he's too shy (for now) to engage the broad SharePoint community, so he has donated his code to Scot Hillier's SharePoint Features project on CodePlex for all to share and hopefully extend. The blog entry below was jointly written by Jonathan and Scot. <Lawrence /> Debugger Feature for SharePoint When activated, the Debugger Feature adds an "Attach Debugger" menu item to the Site Actions menu (see picture below). The feature provisions a simple page, which executes the System.Diagnostics.Debugger.Launch statement, causing an exception to be thrown and the debugger to be auto-attached. In some cases, the debugger cannot attach – for example, when the AppPool is running under a different user account. When that happens, the page will at least give you the correct PID, so you can attach the debugger yourself.
Figure: Attaching the Debugger from SharePoint Beyond this very basic and useful function, this is a great example of how to write a simple SharePoint feature that provisions a page. Included in the VS 2005 solution project are all of the .XML and .DDF files needed to create a feature and then a solution cab file for deployment. Let's take a quick walkthrough of the most important files. The first .XML file, feature.xml, is what defines the feature:
The complete set of parameters can be found at http://msdn2.microsoft.com/en-us/library/ms436075.aspx. The critical element for us is the ElementManifest element, which specifies where WSS can find the provisioning instructions for our feature. The path is relative to the feature.xml, which in turn is relative to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12. More on this when we construct our solution's .CAB file. For now, know that the feature.xml and elements.xml are usually in the same directory. Elements.xml:
Right now, the documentation on the contents of the elements file is fairly light. Looking briefly at our CustomAction element, the important attributes are the GroupId and Location, which tell WSS where to place our new page (the site actions standard menu). The Sequence number is for sorting the menu, 2001 should ensure we are at the bottom. And most importantly is UrlAction, which tells WSS that this will be a hyperlink to the AttachDebugger.aspx page. Notice the relative path token ~site, which indicates the page is located in our current site. From here, I'd suggest opening the VS 2005 solution file and taking a look around. Notice how the directory layout inside the solution is similar to the layout in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE. This is also to facilitate feature development. Check out install.bat and see how we use xcopy to copy the dev tree to the template tree. (BTW, the commented lines in the install.bat should be obvious – we have no need to GAC our assembly or restart IIS for our feature, but you might in future features. It's there if you need them.) Finally, lets look at how the .CAB file is created. The most important file is the .DDF file in the \WSP directory:
It's fairly easy to read, but take a look at the destination paths, which are relative to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE. The location of the AttachDebugger.aspx file must match the TemplateFile Location path specified in the manifest.xml file:
Once you've developed and deployed a feature or two, you'll have that light bulb ("a-ha!") moment about how everything required to implement a feature relates to each other, and then you'll want to create a SharePoint feature for every discreet piece of functionality that you'd like to add to SharePoint! |
| [from the MSXML Blog] As a part of our MSXML4 End of Life plan , we are going to kill bit MSXML4 in the October – December timeframe of this year. This kill bit applies to Internet Explorer only. After the kill bit, web applications will not be able to create MSXML4 objects in the browser. Applications which are not kill-bit aware will continue to work with MSXML4. We are announcing this in advance so that our customers get sufficient time to try their applications with MSXML6 and give us feedback on their experience. Please email us at msxml4@microsoft.com with feedback/questions/concerns. Why: We are going to kill-bit MSXML4 to ensure a secure browsing experience for our customers. We are planning to also remove MSXML4 from the Download Center page within the next 12 months. Support for MSXML4 going forward will be restricted to high impact security issues only. MSXML6 is the latest version available to MSXML customers today. This is where all the functionality, performance and security improvements are going in. In addition MSXML6 provides improved W3C compliance and increased compatibility with System.XML in .Net. The recommendation for MSXML customers is to program using MSXML6 and upgrade apps using older versions to MSXML6. We strongly encourage everyone to start using MSXML6 SP1. MSXML6 SP1 is now available for all supported down-level platforms and can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=d21c292c-368b-4ce1-9dab-3e9827b70604&displaylang=en MSXML Supported Versions: We addressed this in a blog entry http://blogs.msdn.com/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-in-internet-explorer.aspx The summary is: MSXML6 - Should be your first choice. This is the MSXML version that will be carried forward. MSXML6 shipped with Vista and we are working on getting this in downlevel OS Service Packs MSXML3 – This has the advantage of having shipped with every supported OS .We are committed to keeping MSXML3 robust and stable but won't be adding any functional improvements. MSXML4 - This is in maintenance mode with a very high bar for fixes approaching End of Life. MSXML 5 – Exclusively meant for Office. Do not take any dependencies on it. MSXML4 & 6 Differences and Compatibility: Key changes introduced between MSXML4 and MSXML6 and migration are described in the blog entry at http://blogs.msdn.com/xmlteam/archive/2007/03/12/upgrading-to-msxml-6-0.aspx Summary: We believe this is the best plan for MSXML customers going forward – avoids confusion regarding multiple versions, ensures a safe browsing experience when using MSXML and provides a path to use future functional improvements . If you run into issues with the migration or have questions/feedback feel free to contact us at msxml4@microsoft.com . All of the MSXML team is on this alias eager to hear your feedback and assist with the migration. |
