Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / February 2006

Tip: Looking for answers? Try searching our database.

400+ web references in a project

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
marked23 - 25 Jan 2006 23:06 GMT
I have a project that contains 400+ web references.   When I go to do a new
build, I need to update all the web references to pick up any changes in the
web services they reference.

I select the top one, and shift-select the bottom one... then click
"update."  Visual studio goes through every web reference in turn, doing an
update for each one.  It also appears to spawn a background thread (or pool
of threads) for each update.  When Visual studio says it's done with the
updates, it's not nearly done because the background threads are still
working hard to complete the updates.  100% cpu, and memory climbs up to
700mb or so.

So I wait, about two hours.

Then it's done and I can finally do the build.

Is htere anything I can do to speed up this process?  I have to update every
web service... no choice there.

-Mark
marked23 - 27 Jan 2006 20:30 GMT
Oh, and one more thing.  The only thing in this project is all these web
references... No actual code.   Then we use the resulting DLL in a separate
project.

-Mark
Dale - 29 Jan 2006 02:45 GMT
You could alwayd create a script and manually call WSDL.exe.
Signature

Dale Preston
MCAD C#
MCSE, MCDBA

> Oh, and one more thing.  The only thing in this project is all these web
> references... No actual code.   Then we use the resulting DLL in a separate
> project.
>
> -Mark
marked23 - 08 Feb 2006 21:18 GMT
I havn't done something like that before.  Would such a script produce an
identical result?  I mean, would the files be the same so that I could go
back to the IDE and compile?... and the project would never know the
difference?

> You could alwayd create a script and manually call WSDL.exe.
>
[quoted text clipped - 3 lines]
> >
> > -Mark
Dale - 09 Feb 2006 03:10 GMT
There are several options for the scripting, everything from a simple
VBScript application up to a separate C# applicaton.  You could create a text
file with all of the URLs to run WSDL against, or you could create a database
or XML file.  Or even write an application to search for the URL in the
existing proxy class, and then use that URL to get WSDL.exe to get the
updated reference.  All you have to do is replace the existing Reference.cs
files with the proxy class generated by WSDL.exe.

Then, as long as the web service interface hasn't had elements deleted
(interfaces can be added to but existing interface elements should never be
modified or deleted - hopefully), you should be able to compile your existing
code with the new proxy classes just fine.

I suggest looking up WSDL.exe in MSDN Library to see how to call the
application and specify namespaces and output files, etc. to make the output
proxy classes match your application framework.

Signature

Dale Preston
MCAD C#
MCSE, MCDBA

> I havn't done something like that before.  Would such a script produce an
> identical result?  I mean, would the files be the same so that I could go
[quoted text clipped - 8 lines]
> > >
> > > -Mark

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.