I think, Debugging with Edit and Continue and faster compilation are the major ones if not the only factors in day to day development productivity of the developer.
Right now, debugging experience in WAP is not any better than VS 2003 times while using external IIS, And I am sure most of the big applications have to use external IIS because big apps are mostly built using root and multiple sub web-projects.
On the contrary, debugging in WSP works great with external IIS and multi project scenarios work great too.
This issue is a big hurdle for my team to decide whether to go with WAP or WSP. Day to Day development productivity of my developers is what all I care to choose between the two ways.
The Fact that WAP is just released, that may be the reason they don't have much for debugging in WAP, I want to know how does the future looks like for WAP, what are the next long term and short term plans for WAP especially when we want to use external IIS.
Why I am stressing on "External IIS" is Because complex apps are just not possible using today's WAP with local IIS server because the formal requirements of big apps are:
1. Sharing resources like controls, media files etc using virtual directories across projects.
2. Mutiple teams need to work together on a single project, the way they divide their work is using separate sub web-projects
In todays's VS 2005, all above can be configured using external IIS only irrespective of WAP or WSP.
If Microsoft's next plans are to enhance local server to accomodate above things then we may go the WAP way ( though debugging with Edit and Continue sucks today even with using local server, but I am sure they will improve it and make it comparable to WSP ), for example, they may have a way to import all the configurations from external IIS to local server.
Now you guys may be wondering why don't I just jump to WSP, because WSP works great with both external and local server,
well... the main reasons are:
1. Upfront conversion effort: The upfront migration effort that we need to do for our giant projects will be huge if we choose to go WSP way. We have lots of sub projects, around 1000 web pages, I tried converting few projects to WSP, it took me days to just get the compilation going.
On the other side, conversion to WAP was very smooth, no build errors at all, the only catch is ( which I still couldn't find a solution for ), the html errors on individual aspx pages are not shown by VS 2005 at build time ( I think this behavior is by default so that only the code behinds compile to make a faster compile, the html parsing related compilation is deffered till run time ).
The syntax errors show up only when I get to the designer and switch from html to design view for a page, for example, errors like user control's path is not found, <table> end tag is not found etc kind of errors. I tried adding web deployment project too, It catches the errors but may not be all of them and double clicking an error doesn't take me to the error file, and that way, fixing those errors in just a pain, and honestly, at this time I don't know how many of these errors are there and how much time will it take to get them fixed. Note that all above stuff that I talked in this point is just after conversion stuff, once the conversion is completely done, there shouldn't be any issues.
2. Learning Curve for our 20+ of Developers for WSP: WSP's compilation/deployment model will be new for our developers, and I am sure it will need a week of each developers time to get adjusted to the environmnet inspite of one week ufront training that we are planning to depart to all developers. On the contrary, to make the developers get going with WAP will be a piece of cake ( I am assuming ).
I thought of making a comparison chart of WAP vs WSP, and a points mechanism to show my support for the one or the another. Please note that, this chart is based on just my peronnel findings, the information may be wrong. The whole purpose is to collect more information from others and hammer it so that, ultimately, we can get to decide what fits best in a general medium to large scale project environment. I understand that the points given to each aspect will vary according to the actual situation of one's environment, but let's make an effort towards puting the thoughts together atleast.
|
|
WSP |
WAP |
Points |
|
Debugging |
|
|
|
|
1 |
Edit and continue as long as you are developing (just not when a breakpoint is hit), I could change GUI but html only( can't touch designer ) – I added a new button in html and changed it’s property in code behind, Couldn’t add new pages/controls. |
Edit and continue in internal server only, and that too is pain, I could modify the method while control is there and it took the changes, I couldn’t add a new method though, couldn’t touch GUI, so that’s very bad. Can work in our environment if login page can be bypassed and people are working in a single project while debugging, there was no need to stop the debugging.
|
WSP: 300 |
|
2 |
Attach to Process for debugger works great while debugging.
|
No comments |
|
|
Compilation |
|
|
|
|
1 |
Sharing a mulitmedia Related virtual directory through external IIS causes build errors, note that the contents of the directory are present somewhere on a network share, but this issue may be a simple one.
|
No problems. |
|
|
2 |
Developers will set the build settings to No build, which is fastest, and then developers can occasionally switch this setting to use the web site build which is slower but will show all html errors.
|
Faster project builds, but hard to see the html errors, but that shouldn’t be big problem for day to day development. Fastest builds are really a great point for WAP. |
WSP: 100
WAP: 50 |
|
3 |
Shared user controls (using virtual directory) will have to be compiled in each project.
|
No Comments |
|
|
4 |
All good. |
Had to add web deployment project to know the html errors, though the project pages may run great at run time. Double clicking an error from web deployment project doesn’t take to error file, very annoying. But I think that’s just migration time problem only.
|
|
|
Deployment |
|
|
|
|
1 |
We got another options too (we can still have one assembly if we want to by using deployment projects), Note I may not use single assembly for each page option because then 500 dlls have to be loaded by the runtime for our giant project, which I am sure will affect performance, I am not too concerned about memory consumption as we have a plenty of it on our production web servers, I know I am loosing the capability of deploying a single page change only, it may be worth loosing it in contrast to the performance loss.
|
Single assembly for the deployment |
|
|
Others |
|
|
|
|
1 |
I don’t think that we need to do any directory structure changes at all from what we had in VS 2003, we can still use the structure which has a root project and sub web-projects inside, but got to use external IIS server.
|
No directory structure changes. |
|
|
2 |
Huge conversion effort required.
|
Very less upfront conversion effort needed |
WAP: 200 |
|
3 |
Atleast a week extra learning curve required.
|
Very less learning curve needed |
WAP: 30 |