您需要访问共享点服务器，因为没有它您无法模拟您的 Web 部件，您必须将其部署到您的共享点站点以测试它是否正常工作。 调试也会很痛苦。 或者您可以使用 SmartPart，它是一个 Web 部件，充当用户控件的包装器以在共享点站点中显示。
you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.
您不需要 SharePoint 来开发 WebPart。 您可以通过继承System.Web.UI.WebControls.WebParts来开发Web部件。 这是创建 Web 部件的更好方法，除非您需要以下功能，例如
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
在这种情况下您需要通过继承 Microsoft.SharePoint.WebPartpages.WebPart 来开发 Web 部件。 您可以在此处找到更多有用信息
You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like
* Connections between web parts that are outside of a Web Part zone
* Cross page connections
* A data caching infrastructure that allows caching to the content database
* Client-side connections (Web Part Page Services Component)
In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here
如果您不需要执行任何特定于 SharePoint 的操作（即访问列表、其他 Web 部件等），那么您可以像常规 Web 部件（派生自 System.Web.UI.WebControls.WebParts.WebPart 类）一样构建 Web 部件，并且当添加到 SharePoint 站点时它将起作用。
If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.
我想最简单的方法是使用 CodePlex 中的 SmartPart for SharePoint。 项目描述称“SharePoint Web 部件可以托管任何 ASP.NET Web 用户控件。无需编写代码即可创建 Web 部件！”，我想这正是您想要做的。
I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.
ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.
The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.
Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:
If you can put everything inside of a single assembly, deployment will be easier
try to put everything you need into the DLL's that are deployed to SharePoint
use assembly resources to embed JS, CSS, and image files if needed
Strong name the assembly you are building
Most SharePoint deployments end up in the GAC and a strong name will be required
您的用户控件必须部署为 Web 部件是否有任何特殊原因？ 通过 12 配置单元中的 CONTROLTEMPLATES 文件夹或 Web 应用程序虚拟目录中的某个位置，将用户控件直接部署到 Sharepoint 站点是完全可行的，然后您可以使用 Sharepoint Designer 从网页中引用该位置。
然而，如果 Web 部件要求至关重要，那么我推荐 Smartpart for Sharepoint，如前所述。
Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.
If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.
实际上，由于 Web 部件具有“滥用”性质，因此应始终将其部署到共享点的 bin 文件夹中。 如果可能，请始终将 Web 部件部署到 bin，并编写您自己的 CAS 并将其包含在清单中。
Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.
发布评论
评论（10）
您需要访问共享点服务器，因为没有它您无法模拟您的 Web 部件，您必须将其部署到您的共享点站点以测试它是否正常工作。 调试也会很痛苦。 或者您可以使用 SmartPart，它是一个 Web 部件，充当用户控件的包装器以在共享点站点中显示。
you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.
您不需要 SharePoint 来开发 WebPart。 您可以通过继承System.Web.UI.WebControls.WebParts来开发Web部件。 这是创建 Web 部件的更好方法，除非您需要以下功能，例如
在这种情况下您需要通过继承 Microsoft.SharePoint.WebPartpages.WebPart 来开发 Web 部件。 您可以在此处找到更多有用信息
You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like
In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here
如果您不需要执行任何特定于 SharePoint 的操作（即访问列表、其他 Web 部件等），那么您可以像常规 Web 部件（派生自 System.Web.UI.WebControls.WebParts.WebPart 类）一样构建 Web 部件，并且当添加到 SharePoint 站点时它将起作用。
If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.
像典型的 .net 网站一样构建和测试该控件。
解决方案 1 = 控制
解决方案 2 = 托管控件的虚拟网站。
在 Sharepoint 上部署：
您需要签署控件。
将签名的 DLL 放入共享点服务器（Windows/程序集）上的 GAC 中，
在共享点站点上的虚拟服务器根 web.config 中将控件标记为安全。
即
在您的共享点页面中注册组件：
使用控件：
如果您需要使用相同版本号替换控件，则需要回收应用程序池来重新加载。
Build and test the control as you would for a typical .net web site.
Solution 1 = the controls
Solution 2 = dummy website to host the controls.
Deployment on Sharepoint:
You'll need to sign the controls.
Drop the signed DLL into the GAC on the sharepoint server (Windows/assembly)
Mark the control as safe in the virtual server root web.config on the sharepoint site.
i.e.
Register the component in your sharepoint page:
Use the control:
If you need to replace the control using the same version number, then you'll need to recycle the app pool to reload.
我想最简单的方法是使用 CodePlex 中的 SmartPart for SharePoint。 项目描述称“SharePoint Web 部件可以托管任何 ASP.NET Web 用户控件。无需编写代码即可创建 Web 部件！”，我想这正是您想要做的。
I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.
设置我的机器来为 Sharepoint 进行开发花了我几天的时间。
请参阅 http://weblogs .asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
Setting up my machine to develop for Sharepoint took me a couple of days.
See http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
如果是非常短期的事情，Microsoft 有一个有时间限制的 WSS 评估 VPC 映像：
WSS3 SP1 开发人员评估 VPC 映像
如果您现在没有时间/资源来设置自己的 VPC 映像，这将帮助您入门。
If it's a very short-term thing, Microsoft has a time-limited WSS evaluation VPC image:
WSS3 SP1 Developer Evaluation VPC image
That will get you started if you don't have time/resources to set up your own VPC image right now.
ASP.NET Web 部件在 SharePoint 中的工作方式与在 ASP.NET 中的工作方式相同。 这就是我要采取的路线（派生自 ASP.NET Web 部件的自定义控件 类）。 这将减轻在 SharePoint 服务器上实际开发的任何要求。
您将遇到的唯一问题是您将无法利用 SharePoint 框架。 如果您在 SharePoint 中执行任何高级操作，那么这是一件大事。 但是，SharePoint 是 ASP.NET 加上一些附加功能，因此您可以使用 System.Web.UI.WebControls.WebPart 类应该在 SharePoint 中工作得很好。
当您从纯 ASP.NET 迁移到 SharePoint 时，一些注意事项将有助于减轻您的痛苦：
这是相关的博客文章； 开发基础SharePoint 2007 中的 Web 部件
ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.
The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.
Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:
Here is a relevant blog post; Developing Basic Web Parts in SharePoint 2007
您的用户控件必须部署为 Web 部件是否有任何特殊原因？ 通过 12 配置单元中的 CONTROLTEMPLATES 文件夹或 Web 应用程序虚拟目录中的某个位置，将用户控件直接部署到 Sharepoint 站点是完全可行的，然后您可以使用 Sharepoint Designer 从网页中引用该位置。
然而，如果 Web 部件要求至关重要，那么我推荐 Smartpart for Sharepoint，如前所述。
Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.
If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.
实际上，由于 Web 部件具有“滥用”性质，因此应始终将其部署到共享点的 bin 文件夹中。 如果可能，请始终将 Web 部件部署到 bin，并编写您自己的 CAS 并将其包含在清单中。
Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.