开发要导入到 SharePoint MOSS 2007 的 ASP.Net 用户控件
如果这个问题已得到解答，我深表歉意，但我找不到类似的问题：
我正在为 MOSS 2007 开发一个 Web 部件。我正在使用 WSPBuilder 构建一个可视化 Web 部件（ascx），一切正常，但开发/调试周期只是慢得令人痛苦，所以我想知道是否可以（不会太痛苦）使用 .Net Web 应用程序项目以及所有良好的 F5 调试来更快地开发用户控件，然后将最终产品导入到我的 SharePoint 视觉效果中网络部分。
用户控件与 LOB 系统 (SQL) 交互，并且根本不引用 SharePoint API。 （我将其构建为 Web 部件的原因是因为我不需要另一个 Web 应用程序来运行此页面，因此将其放入我现有网站上的新 Web 部件页面上的 Web 部件中是我认为最好的解决方案。）显然需要将我的数据访问类导入（参考？）到我的“临时”网络应用程序中，但我认为这不会太麻烦。
我意识到这将需要额外的努力来完成此设置，但我认为回报将是减少使用小型 Web 应用程序的实际用户控件的开发时间，而不是必须使用编译/构建 WSP/部署 WSP/重置 ISS/测试/进行 MOSS 要求的更改/重复循环。 （我想 SP2010/VS2010 已经用可用的本机 SharePoint 工具宠坏了我。）
更新：
我已经成功构建了一个简单的网页应用程序，并在该页面上加载了我的 UC。 （我必须注释掉 WSP Builder 在创建 Web 部件时为我添加到 UC 的所有 Sharepoint 导入和注册语句。）我添加了对我的实用程序类的引用（我将其保留在原始文件中的 obj\Debug 文件夹中） SharePoint 项目）。我花了一段时间修改所有内容才使其正常工作，但步骤最终非常简单，我认为我可以为未来的项目快速复制这些步骤。设置完成后，我能够快速设计 UC 并使用典型的 F5 调试周期构建 UC 功能。除非有人能告诉我为什么这不是一个好主意，否则我计划在未来的项目中重复这一点！感谢大家的意见。
。
更新2
嗯，我不确定我做了什么，但将 UC 移回 SharePoint 被证明是很麻烦的。第一次这样做时，我花了几个小时让它在 SharePoint 中运行，这让我怀疑这是否值得。然而我很固执，又尝试了一次。这次，我仅将标记复制并粘贴到 ascx 文件中的“标头部分”（包含所有 <%@ . . . %> 语句的部分）下方，一切都很顺利。我想我第一次一定是无意中改变了一些东西。我想我会继续这种模式，因为在 ASP.NET Web 应用程序中构建和测试 UC 的速度要快得多。 （同样，只有当您不在 UC 中的任何位置引用 Sharepoint API 时，这才有效。）
Apologies if this has been answered, but I could not find a similar question:
I am developing a webpart for MOSS 2007. I am using WSPBuilder to built a visual webpart (ascx) and everything works fine, but the development/debug cycle is just painfully slow, so I'd like to know if it is possible (without being too painful) to develop the user control faster using an .Net Web Application project with all of the nice F5 debugging, then import the final product into my SharePoint visual webpart.
The user control interacts with a LOB system (SQL) and does not reference the SharePoint API at all. (The reason I am building this as a webpart is because I don't need another web app to run this one page, so putting it into a webpart on a new webpart page on my existing site is the best solution IMO.) I would obviously need to import (reference?) my data access classes into my "temp" web app, but think that would not be too much trouble.
I realize this will be extra effort to get this set up, but am thinking the payoff will be reduced development time of the actual user control using a little web application vs having to use the compile/build WSP/deploy WSP/reset ISS/test/make a change/repeat cycle that MOSS requires. (I guess SP2010/VS2010 has spoiled me with the native SharePoint tools available.)
Update:
I have successfully built a simple web app with one page and loaded up my UC on the page. (I had to comment out all of the Sharepoint Import and register statements that WSP Builder added to the UC for me when I created the webpart.) I added references to my utility classes (which I left in the obj\Debug folder in the original SharePoint project). It took me a while tinkering with everything to get it to work, but the steps ended up being pretty simple and I think I can replicate the steps quickly for future projects. Once it was set up, I was able to rapidly design the UC and build in the UC functionality using the typical F5 debug cycle. Unless someone can show me why this is not a good idea, I plan to repeat this for future projects! Thanks to everyone for thier input.
.
Update 2
Well, I am not sure what I did but moving the UC back into SharePoint proved to be troublesome. The first time I did it, I spent several hours getting it to work in SharePoint, making me question whether it was worth it. However, I am stubborn and tried it again. This time, I only copied and pasted the markup below the "header section" (the part with all of the <%@ . . . %> statements) in the ascx file and everything went perfectly. I think I must have changed something inadvertantly the first time. I think I will continue this pattern as it is so much faster to build and test the UC in an ASP.NET web app. (Again, this only works if you are not referencing the Sharepoint API anywhere in the UC.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里的答案是SmartPart。它非常适合您所描述的场景。使用“vanilla”ASP.NET 创建用户控件并将其作为 SharePoint 中的 Web 部件非常容易。我在 我的网站上概述了从 ASP.NET 网页迁移到静态绑定 SmartPart 的步骤博客。
The answer here is the SmartPart. It is perfect for just the scenario you are describing. Very easy to create a Usercontrol using "vanilla" ASP.NET and have it work as a webpart in SharePoint. I've outlined the steps to migrate from ASP.NET webpage to statically bound SmartPart on my blog.
您想要实现的目标肯定是一个好主意。
只需记住对您的用户控件进行强命名，将其放入服务器的 GAC 中，更新 SharePoint 80 的 web.config 的 SafeControls 部分。
所有这些设置都是一次性的，在每次连续构建（Web 控件）之后，您只需在 GAC 中部署控件（使用强制部署）并重置 IIS。
您可以通过选择“选择项目”并选择您刚刚部署的程序集来将此控件添加到 VS 中的工具箱。
此外，您还可以创建一个测试 ASP.NET 页面来测试控件的功能。
What you intend to achieve is surely a nice idea.
Just remember to strong name your user control, drop it in your Server's GAC, update SafeControls section of your SharePoint 80's web.config.
All these setps are one off, after each successive builds (of your web control), you have to just deploy the control (used forcede deploy) in GAC and reset IIS.
You can add this control to toolbox in VS by selecting 'Choose Items' and selecting ther assembly you just deployed.
In addition you can create a test ASP.NET page to test the functionality of your control.