I have found many post in the web about how easy is to develop and debug custom Visual Webpart, here are a couple of great references

• http://blogs.msdn.com/bethmassi/archive/2010/01/28/creating-a-sharepoint-visual-web-part-using-visual-studio-2010.aspx
• http://www.helloitsliam.com/archive/2009/10/20/sharepoint-2010-–-create-a-visual-web-part.aspx
• http://blogs.pointbridge.com/Blogs/nielsen_travis/Pages/Post.aspx?_ID=32

The problem is that there is not much talking about how to deploy the packaged Webpart on a different server. I run into this issue following the last post mentioned above because I am trying to deploy a custom Webpart to analyze the Claims inside a Token in a Claims based Authentication Sharepoint Web Application.

I finally came across this post (http://dotnet.sys-con.com/node/1208275) which details the deployment process as follows and is a recommended reading BWT. I am considering that you have a .WSP Webpart packaged by Visual Studio 2010 Beta.

1. Add-SPSolution c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp
2. Install-SPSolution –Identity SharePointProject2.wsp –WebApplication http://sp2010 -GACDeployment

I will complement that post adding the final steps you should run to actually be able to see that webpart on your web application!

When adding a web part while editing a sharepoint page you might find that not all available webparts are show. This might happen if your Site Collection has not enabled all features and is also necessary for activating custom webparts. You should do the following as a Site Collection administrator,

1. Site Actions
2. Site Settings
3. Manage Site Features
4. Site Collection Features

Hope this helps!

Well, I spent a couple of days working with the Sharepoint 2010 Beta and have a couple of IMPORTANT Operational Tips to keep in mind when managing the Beta at least. I have an on-premise deployment (pre-production) and a cloud deployment on Amazon EC2 (production) and in both places I run into issues by limiting the log files growth.

We expect to see this monitored on the SCOM Management Pack when the product hits RTM.

Lessons Learned

1. Watch out the Log files on File System: By default on “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS” On Sharepoint generated 147Gb of log files in two weeks! Yes, 147Gb, this is kindly we fixed by the RTM release. But you should configure Central Administration > Diagnostic Logging to limit the space available for log files. I configured 1Gb for our Cloud deployment.
2. Watch out the WSS_Logging Database: When you do a Single Server installation using SQL Express 2008 to host Sharepoint DBs, you must watch out for the growth of the DB named “WSS_Logging” which usually resides on “C:\Program Files\Microsoft Office Servers\14.0\Data\MSSQL10.SHAREPOINT\MSSQL\DATA”. I had one instance which reached 4Gb and put my SQLExpress instance to the limit (Here is someone who run into the same issue). That DB cannot be truncated as it is not supported right now and it takes care of analytics of the web traffic. You can disable the Health and Data Collection gathering from Monitoring > Reporting > Configure usage and health data collection, however web analytics is very neat to be left apart.
   I was not able to find a procedure to migrate that DB to another server, so I had to disable the feature.

Key Takeaways

1. Limit your log files usage.
2. Deploy on server-farm mode to move the WSS_Logging db to another db server.