I am really having quite a time getting VS 2005 up and going... just enough
seems to be different that it makes it hard to hit the ground running. I had
a number of problems getting it work right at all with web apps when I had
installed IIS after installing VS 2005 on my PC. I un-installed VS, and then
re-installed it, which did fix some of the acces issues, but lately I am
having two (so far) real show stoppers. These are very simple I am sure, and
the answers are just for some reason eluding me.
1) I noticed that in 2005 (as opposed to 2003) when creating a web service,
VS does not automatically create a web.config. However, I can't run the
application without one, so why doesn't it just create one? I CAN run it in
the "test" mode within visual studio, but if I publish it to a web share and
try and do "http://localhost/mywebservice/service.asmx" it won't work until I
add that web.config.
2) I want to expose some wellknown types as SOAP objects for webservice
calls. In 2003, I simply add elements to the web.config on the remoting
server like this:
<system.runtime.remoting><application><service><we llknown
type="nnnn.mmmm.className, assembly" objectUri="myObject.soap" />....
In 2005 however, the <application> element doesn't seem to be defined in the
schema that .NET is using, as I get a complie-time error saying "cound not
find schema information for the element 'application' and subsequent errors
for each elemetn within <application> What am I missing here? Is there some
new way to expose web services? What about the client?
3) In 2003, I typically exposed service layer functions through a web
service, by adding an ASP .NET web service project to my solution, after
first creating a web-shared folder under my solution (such as
..../Projects/MySolution/MyRemotingServer". I then created the web service
application htp://localhost/MyRemotingServer/ which caused it to be created
in that folder. This also made source control easier. I noticed that in
2005 when doing this, my application won't run, because apparently the ASP
..NET process by default does not have access to my web shared folders. Now,
perhaps it does if I were to create them under wwwroot? Is this a
consequence of the fact that .NET 2.0 is more secure and locked down than
previous versions? Does this mean that I will now have to, in addition to
all he other options I need to deal with, now explicitly grant the ASPNET
user account read / edecute process on every web share, or is something just
mis-configured here?
It seems like there aught to be a concise listing of tasks that are
substantially different in 2005 to make it easier to port over from 2003.
This has been so frustrating so far. I would greatly appreciate any hepl
anyone can provide Thanks.
Jim
