0

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.

Improve this question

1 Answer 1

Reset to default
0

You could do it without any problem, as long as you don't make reference to the SharePoint API. The developpement cycle in 2007 is extremely slow, and that kind of optimization can make you gain lots of time.

Improve this answer
3
  • That is my thought too. I was hoping my MOSS dev days were over, but there are still plenty of companies (including mine) that haven't upgraded, so if I can minimize my time working on these projects, I'm a happier guy! I am also curious if I could build the project using VS2010 Sharepoint tools, then use the WP in 2007 if there are no SharePoint references other than the generic ones in the WP class? Thoughts?
    – user2255
    Mar 14, 2011 at 17:28
  • You can develop completly from VS2010 for SP2007. For WSPBuilder, I don't know if they built a version for VS2010... I am using the MSBuild-based solution "STSDEV" and I can do all my development (2007 AND 2010) from my Visual Studio 2010 environment!
    – Sébastien Levert
    Mar 14, 2011 at 19:12
  • I am using VS2010 for this project and WSPbuilder's latest version works great. My question in the comment above was whether I could build a "visual webpart for SP2010" using the VS2010 Sharepoint SPIs, then deploy and use that webpart to MOSS. I'm not sure if it will work that way. The reason I question it is because when WSPbuilder builds my WSP, it says that the WSP is 2007 and 2010 compatible, so it makes me think I might be able to deploy a SP2010 webpart to MOSS if there are no SharePoint API references. As far as my original question, see my update above.
    – user2255
    Mar 15, 2011 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.