Last post Aug 07, 2008 02:17 PM by redwing19
Aug 07, 2008 02:17 PM|redwing19|LINK
We originally had a Web Application Project where a separate signed/strong-named assembly was created for each page and deployed to the server. When we wanted to update an individual page, we could re-compile the Web Application Project using the Web Deployment
Project, and just copy over the affected .dll for appropriate page, leaving everything else on the server intact.
This worked, and allowed us to make updates to pages without having to re-deploy the whole site...
Then the problem came up of adding and deploying new pages. We'd add a new page to the Web Application Project, pre-compile and sign using the Web Deployment Project, copy over the new .dll, .compiled, and .aspx marker files for the new page to the server...but
when we attempted to access the new page in a browser, we'd get the "This page has not been precompiled" error.
I found that if, in addition to the new files for the page, we re-deployed the main dll for the Web Application Project, then the new page works fine and is accessible from a browser.....so we figured that the main dll for the Web Application Project must
contain some sort of manifest, listing each page associated with the project. But for our purposes re-deploying the main dll isn't desirable, because who knows what's in that main dll (I wouldn't think there'd be much since each page is compiled into its
own assembly, but who knows)...and if we're trying to deploy different versions of our app to different servers, it becomes much more difficult to maintain with this main dll floating around.
So, wanting the ability to deploy new signed assemblies for new pages without having to re-deploy the main dll, we started investigating Web Site Projects again. Since, there is no main dll to be deployed with a Web Site Project, it seemed that we might
be able to accomplish this.
After doing some testing we found, that yes, indeed, we can add new signed pre-compiled files to the server, and access them in a browser no problem....hurray, we thought.....but then we decided to do some more testing by deploying additional unsigned precompiled
binaries for other pages and found that they too could be accessed from the browser no problem. Getting more confused, we deleted the signed binaries for a few pages from the server, and replaced them with unsigned binaries with the same name.....and they
also worked fine.
So now we're all scratching our heads wondering what the point of signing/strong-naming page-level assemblies in a Web Site Project?? Signed or unsigned, using different keys, etc., it apparently doesn't matter, the pages are always run.....could someone
shed some light on this? Why is this option available if it has no meaningful effect?
Web Application Project
Web Deployment Project
Separate Assemblies for each page
Web Site Project