REPOST: Guru Challenge

[Scott Allen]

I am quite sure that the problem is a software configuration issue.

I have a hunch the problem is network related. Most long operations
like you describe are because of Windows going off and trying to find
some netbios name that doesn't exist anymore or trying to do a reverse
name lookup on the computer name your computer used to have 6 months
ago.

I'm not sure how I'd track this down exactly, but I think I'd try some
tools from sysinternals.com to monitor registry, file, and network
access. I might even try a fresh install of IIS and give myself a new
metabase.

 

[Juan T. Llibre]

re:

I really don't think you understand what I'm even saying.

Perhaps you haven't supplied the correct information,
or asked yourself the correct questions, or listened well enough.

My only point is that you're presenting a unique situation which I have
never seen reported, so you should look to how your system(s) are
configured for the answer.

You have 3 things at play here :

1. Your hardware configuration
2. Your software configuration
3. Your network environment ( both hardware and software )

You'll need to check all of them.

re:

You telling me that your system does the job in a short period of time does not, in any
way, mean that MY problem is specs.

No one is disputing that, as far as hardware goes.
Sometimes a comparison helps.

Don't your disk/software images have specs, too ?

I've seen no end of problems come from standard disk images,
starting with name ambiguities and running a whole gamut
of items which need individual configuration.

Networked environments are particularly sensitive to naming ambiguities,
and they could lead to, precisely, the type of problem you are describing.

re:

Since creating a web application involves VS.NET and IIS communicating and the
configuration of the two products configured properly, it may be an IIS configuration
issue, it may be a VS .NET configuration issue

Your original phrasing was :
"It seems that the IIS directory gets created right away, but it is not
configured as an application directory until several minutes go by."

And the *same* problem exists in *all* the machines, right ?
If so, this, again, points to name ambiguities.

re:

it may be a permissions issue (this is, after all, a corporate desktop image I'm talking
about).

That could very well be.
Many IIS settings depend on machine-specific configurations.

How about something simple, like the TCP/IP stacks ?
When you run applications on the localhosts, do the sites respond quickly ?

 

[Juan T. Llibre]

One last suggestion :

Take ONE of the machines which exhibits the behavior,
format it, and install the OS, IIS and VS.NET manually.

Then, in a standalone environment, check its speed when creating applications.
If it's not working as fast as it should, your hardware is the problem's source.
( I know you already said that's not the source, but follow through... )

If it's working OK, connect it to the network and check its app creation speed.
If it's *then* not working as fast as it should, your network is the problem's source.

If it's working OK after having connected the box to the network,
you can pretty much assume that the disk images are the source of the problem.

That will take you, tops, 2-3 hours, and will nail down the problem
much more easily than any other procedure I can think of.

Good luck!

 

[Guest]

Juan, with all due respect, I think you haven't listened well enough. I
understand what the problems *might* be and I know how to test particular
scenarios. I have been using .NET for nearly 5 years and on many different
systems.

My post asked if anyone knew why creating a localhost web application would
take an inordinate amout of time. I told you that hardware has been ruled
out and your response is now essentially "check your environment". That's
not a very helpful answer, especially since I knew all of that coming in.

Just because you haven't experienced the scenario I'm discussing doesn't
mean it doesn't exist for others, but it may mean that perhaps you don't have
anything to contribute to the discussion.

You categorically stated:

"All I'm telling you is that .Net, nor even VS.NET, whether 2003 or 2005,
have nothing to do with your problem."

Why in the world would you say such a thing? Anyone who knows anything
about VS.NET and ASP.NET knows that in order to make a new web application,
VS.NET must communicate with IIS to create the directory, configure it as an
application and set the correct access permissions. For you to say such a
thing without knowing anything about my software configuration is ridiculous
and clearly shows that you have a limited understanding of the subject.

If you don't know, then don't post or just say that you don't know, but
don't just make ridicuous statements to try to prove you know something that
you don't.

I know you say you are an ASP.NET MVP, but you haven't displayed anything to
me that even implies you know how to read a post and respond with relevant
information, much less a good knowledge of ASP.NET.

 

[Guest]

"last suggestion"? When did you make your first suggestion? Again, I think
you might just want to sit this one out. You are asking me to tear down a
house to find out why a door was creaking. You haven't offered one thing to
look at or check.

I know that I could re-build a machine from scratch, but gee, that's why I
wanted to some help on things I could check first.

It's ok to say you don't know if you don't know. Even better, you don't
have to respond to posts if you don't have anything valuable to contribute.

 

[Juan T. Llibre]

Good bye, Scott.

I wish you luck in solving your problem.

 

[Juan T. Llibre]

Like I said just now, Scott : good luck solving your problem.

I'm sorry you have to resort to flaming me in order
to feel better about your frustrations with your problem.

In the end, you'll wind up doing what I suggested.

 

[George]

Wow Scot, are you all frustrated over there?
You are not making friends here
I am even afraid to say anything (you might bark at me as well

Anyway i try. Never had a problem like you have but having some experience might suggest something useful.

Earlier you said that all machines in your corporation.

So i would think it has something to do with your mandatory company software running on all those machines.

-1. Check Windows even log. It might offer some clues at why is it happening.
0. Are you going thorough Frontpage extension to create the project? I hope not.
1. The antivirus is a viable candidate and i would definitely try to uninstall it (not just disable, i have an experience when disabling did not do a thing but uninstalling did the trick)
2. Your corporate network. Is it possible that localhost name resolution is not working well on your network. Try to create the project on 127.0.0.1 and see if there will be any difference between that and localhost. Or even try to disconnect you computer from the netwrok and check if it's making any difference.


Thanks
George.

 

[Guest]

Thanks. It has been solved by George, who actually had some suggestions of
things to try, rather than telling me to rebuild my pc.

 

[Guest]

LOL: or, in the end, you'll learn how to troubleshoot.

 

[Guest]

BINGO! That did the trick. Thanks George!

It took about 2 seconds after that. Do you think that this could be
resolved with an entry to the "hosts" file? If not, any thoughts on what
could clear this up?

Thanks again!

 

[Juan T. Llibre]

Maybe, if you had answered my questions :

How about something simple, like the TCP/IP stacks ?
When you run applications on the localhosts, do the sites respond quickly ?

I could have had enough information to help you.

Just because you can do things quickly using 127.0.0.1,
doesn't mean you have solved your problem.

At most, you have worked around it.

You *should* be able to work sites with localhost, instead of with 127.0.0.1
If you can't, you *still* have a TCP/IP stack problem, like I said.

That could come back to bite you.

In any case, I see you prefer to lambast someone who is trying to help you,
instead of being courteous regarding that someone's attempts to help you.

I'll try not to interfere between you and your problems again.

 

[Scott M.]

Maybe, if you had answered my questions :

I could have had enough information to help you.

Maybe if you had ASKED those questions, I would have answered you, but you
didn't!

Just because you can do things quickly using 127.0.0.1,
doesn't mean you have solved your problem.

Yes, it does because it pointed me to what the problem centers around: the
resolution of server names.

At most, you have worked around it.

You are very quick to come to judgements. This is like the 3rd time you've
declared what I'll have to do to solve my problem and, in each case, you've
been wrong because YOU simply won't calm down and admit that you never
really asked me any questions at all, you just started right in disputing my
telling you that the hardware wasn't the problem.

You *should* be able to work sites with localhost, instead of with
127.0.0.1
If you can't, you *still* have a TCP/IP stack problem, like I said.

I know what I *should* be able to do and based on the help of someone who
actually offered some, I have located the problem and it has been solved
(and it was NOT a TCP/IP stack problem like you declared) it was a simple
problem with the hosts file.

That could come back to bite you.

Not really sice the problem is now solved.

In any case, I see you prefer to lambast someone who is trying to help
you,
instead of being courteous regarding that someone's attempts to help you.

I'll give you an "A" for effort, but you get an "F" for actually suppling
anything that was remotely helpful. In fact, you've been stubbornly
declaring what my problem is, what I'll have to do to solve it and you never
ONCE actually asked me for any information.

I'll try not to interfere between you and your problems again.

THANK YOU!


Juan T. Llibre, ASP.NET MVP

 

[Juan T. Llibre]

re:

Maybe if you had ASKED those questions, I would have answered you, but you didn't!

You are quoting the very same message in which
I asked those questions in your current reply.

I edited out your flames, so you can read them again.

You were too intent on flaming me, instead of reading what I wrote.

But, that's OK, Scott. Have a nice life.

 

[Kevin Spencer]

You categorically stated:

"All I'm telling you is that .Net, nor even VS.NET, whether 2003 or 2005,
have nothing to do with your problem."

Why in the world would you say such a thing? Anyone who knows anything
about VS.NET and ASP.NET knows that in order to make a new web
application,
VS.NET must communicate with IIS to create the directory, configure it as
an
application and set the correct access permissions. For you to say such a
thing without knowing anything about my software configuration is
ridiculous
and clearly shows that you have a limited understanding of the subject.

I can tell you why he would say such a thing. Because many of us use the
same product without any problems whatsoever, in terms of speed, etc. I have
it installed on both my home and work machines, and we have it here at the
office on a number of machines. No problems. If the problem were in the
Visual Studio.Net application, it would exist in all copies of the
application. It doesn't. Therefore, it is outside the application, as Juan
stated.

The issue you mentioned ("communicate with IIS") does not indicate a problem
with Visual Studio. It indicates aproblem in the environment in which Visual
Studio operates, as Juan indicated. The fact that you figured out that it
was an issue with a hosts file confirms this.

Juan was being as helpful as he could, by attempting to reduce the number of
possible areas where the problem could originate. He speaks about what he
knows, and keeps silent about what he does not (or can not) know, as any
helpful person should. When attempting to solve an issue, knowing where the
problem does NOT originate is part of the problem-solving process. To quote
Sherlock Holmes, "When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." While this is not the only means to
solving a problem, it is certainly a useful one. And considering the size
and scope of Visual Studio, it eliminates quite a few possibilities.

While your frustration with the problem is understandable, your anger at
Juan is misplaced.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[Kevin Spencer]

George, like Juan, myself, and the others who tried to help you, made a few
educated guesses. He had the advantage of having heard some of the ones that
didn't pan out, ubt he certainly did not present all of the possible causes
of your issue. The fact that one of his guesses, among the myriad
possibilities, happened to be the issue, does not make him a better person
than Juan, or any of the other people who have tried to help you. It is a
simple fact that you always find something in the last place you look for
it. After all, once you find it, you stop looking.

Juan is one of the most helpful paricipants in this newsgroup, and has
pulled many a foot out of the fire. Your anger with him is misplaced, and
illogical. I hope you don't program with that logic! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

 

[George]

That i do not know.
It can be problem on your network or some software (like antivirus) messes up the TCP/IP.

You can easily check by disconnecting your PC from the network and try create project on localhost.


George.


BINGO! That did the trick. Thanks George!

It took about 2 seconds after that. Do you think that this could be
resolved with an entry to the "hosts" file? If not, any thoughts on what
could clear this up?

Thanks again!

 

[Scott M.]

Kevin, I appreciate your help, but I don't need a lecture. I, myself have
been a participant of these NG's for years. But I certainly don't need
someone arguing with me over a point that is mute. Juan has done nothing
but that since his first post here. I don't doubt that he may have been
helpful to others in other circumstances, but he has not been here.

Telling me to rebuild my machine and step-by-step see where the problem
arises or to argue that hardware IS my problem because everything works fine
on his system is not really the kind useful troubleshooting advice I was
asking for.

George and yourself provided things that I could actually look at, things
that I could check, places I could look and that was/is helpful to someone
who is troubleshooting a problem.

It's one thing to offer a guess and try to be helpful, it's entirely
different to insist that your opinion is correct when you have not asked any
questions or provided any direction as to what to try. This is what Juan
has done here and, I'm sorry, but I have no patience for that.

Thanks again for your help.

 

[Scott M.]

Kevin,

First of all, I am one of those people in the "us" you describe below that
use (and have used) this product without any problems what-so-ever. I have
been using .NET since early betas and also have it installed on several
different machines at home as well and I have not encountered this behavior
in the past either, hence my post.

I never said that the problem is with VS.NET (the software programming of
it) so I'm not sure why you are saying that I did. What I said was that
there is certainly the possibility that the configuration of VS.NET and/or
the configuration of IIS may be the culprit because the two have to
communicate in order for web applications to be created. Within that realm,
there are a number of variables that could be the cause. For Juan to
categorically state (which he did) that the problem is not with VS.NET or
IIS without knowing anything at all about the systems in question and their
configuration is hardly the sign of someone who has any form of in-depth
knowledge of the subject. And, to state this after categorically stating
that my hardware is the problem (which he also did) when I had already told
him that this was ruled out and again he had not known anything else about
the environment just tells me that Juan wants to be heard. He wants to be
agreed with and he wants his word taken as final. Again, I'm sorry, but
that is not being helpful.

I can tell you why he would say such a thing. Because many of us use the
same product without any problems whatsoever, in terms of speed, etc. I
have it installed on both my home and work machines, and we have it here
at the office on a number of machines. No problems. If the problem were in
the Visual Studio.Net application, it would exist in all copies of the
application. It doesn't. Therefore, it is outside the application, as Juan
stated.

The issue you mentioned ("communicate with IIS") does not indicate a
problem with Visual Studio. It indicates aproblem in the environment in
which Visual Studio operates, as Juan indicated. The fact that you figured
out that it was an issue with a hosts file confirms this.

Not so fast. If VS.NET is set up to use FrontPage Extensions and/or File
Sharing to communicate with IIS, then that is a VS.NET issue, not an
environment issue. You can't just rule out VS .NET and IIS without first
looking into the configuration of each.

Juan was being as helpful as he could, by attempting to reduce the number
of possible areas where the problem could originate. He speaks about what
he knows, and keeps silent about what he does not (or can not) know, as
any helpful person should. When attempting to solve an issue, knowing
where the problem does NOT originate is part of the problem-solving
process. To quote Sherlock Holmes, "When you have eliminated the
impossible, whatever remains, however improbable, must be the truth."
While this is not the only means to solving a problem, it is certainly a
useful one. And considering the size and scope of Visual Studio, it
eliminates quite a few possibilities.

I agree. So when I repeatedly informed Juan that hardware has been ruled
out and he repeatedly insisted that this was, in fact, my problem, I knew
that he was not someone who understands how to troubleshoot.

While your frustration with the problem is understandable, your anger at
Juan is misplaced.

To each his own.

 

[Juan T. Llibre]

re:

when you have not asked any questions or provided any direction as to what to try

Scott, going into denial really doesn't help.

Let me repeat the dialogue :

You :

Maybe if you had ASKED those questions, I would have answered you, but you didn't!

The text which you say I didn't write :

How about something simple, like the TCP/IP stacks ?
When you run applications on the localhosts, do the sites respond quickly ?

If you had been paying attention to the suggestions being made,
instead of looking to vent your frustration with your problems on me,
you could have found out that the TCP/IP stack *was* the problem
much sooner ( Even sooner than George's suggestion ).

You *still* have the TCP/IP problem, btw.
Working around it by using 127.0.0.1 will probably come back to bite you.

But don't mind me. Have a nice day.