i've posted questions on this board several times requesting information regarding auto deployment - no one seemed to have an answer (and i don't really blame anyone because the documentation on that topic is very scarce)<BR><BR>last week, i came across this article: http://www.dotnet247.com/247reference/a.aspx?u=http://msdn.microsoft.com/library/en-us/dnadvnet/html/Vbnet10142001.asp?frame=true<BR><BR>it answered some of my questions - but the author recommends compiling the forms you wish to auto deploy into a dll rather than an exe - however, in my tests i have been unable to auto deploy a dll - it has only worked for exe's<BR><BR>plus, it appears that visual studio.net must be installed on the server on which the forms reside that you wish to auto deploy<BR><BR>is it just me, or does that seem a little wrong? shouldn't the only requirement be to have the .net framework installed?<BR><BR>if any of you have any feedback regarding auto deployment, please reply - there is a veritable dearth of information out there on this subjectboy do i feel stupid! - and believe me, it's not the first time<BR><BR>disregard all that stuff i said in my last post about not being able to use a dll and needing vs.net, etc.<BR><BR>i had my stub application pointing at the wrong directory - a stupid path error<BR><BR>after correcting that error, i found the following that may be helpful to some of you:<BR><BR>? vs.net is NOT needed on the server - just the .net framework (the client also needs the framework installed, btw)<BR><BR>? it seems that compiling a deployable form as an exe or as a dll will work equally well - i don't know why the author of the article i referred to earlier recommended compiling the form as a dll - he didn't offer any explanation - it seems to be that it would be better to compile it as an exe - that way it could actually be executed as a stand-alone program if need be rather than necessarily being deployed<BR><BR>? in iis, in the virtual directory settings, "Execute Permissions" must NOT be set to "Scripts and Executables" - i don't yet know why, i just know it doesn't work<BR><BR>i hope this helps someonei don't like vagueness<BR><BR>this auto deployment issue leaves two main questions in my mind - i will ask them here in hopes that someone may have some answers<BR><BR>1) would a dll be better than an exe in the auto deployment model as i have described? if so, why? if not, why not?<BR><BR>2) why can't "Execute Permissions" in the virtual directory be set to "Scripts and Executables"?<BR><BR>tiaif i use my browser to try to open a deployable form (as opposed to using a stub app) there are some interesting results<BR><BR>if i point the browser to the url of my form compiled as an exe, two instances of the form are opened<BR><BR>if i point the browser to the url of my form compiled as a dll, the contents of the dll are displayed in the browser - the exact same contents i see if i open the dll in notepad<BR><BR>would that constitute a security issue? maybe that would be one argument in favor of compiling into an exe - but why would the browser open multiple instances of the exe-based form?<BR><BR>obviously, using a stub app instead of a browser would solve this problem with the exe forms, but the fact that i can view the contents of a dll via the browser made me raise my eyebrows a bitauto deployment is really cool!<BR><BR>you guys should check it out<BR><BR>