By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,896 Members | 1,983 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,896 IT Pros & Developers. It's quick & easy.

How to determine if I am in a web or a windows application

P: n/a
Hello to all,

I use a lib class to handle all my exeption errors ocured in my objects.
Since my objects are used in windows applications as well as in web
applications, I would like to determine in my lib class if she is serving a
web or a windows application. Is there a neat way to detect this.

Greets

Jean.Paul
Sep 21 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Well, you could query System.Web.HttpContext.Current, but personally I tend
to design libraries to be ignorant of their caller, and just do their own
job. Is there something specific you want to do differently? As a different
design (such as passing in some kind of service interface) may be more
appropriate.

Marc
Sep 21 '06 #2

P: n/a
Marc,

Well, I have to tell my users what error they encountered, in a winform i
can use a MessageBox and in a webform I have to use a popup. Thats the mean
reason.
The data object have to live on there own without knowing where they are
used, just my exepton handler has to know where the object was used.

greets
jp

"Marc Gravell" <ma**********@gmail.comschreef in bericht
news:u3**************@TK2MSFTNGP03.phx.gbl...
Well, you could query System.Web.HttpContext.Current, but personally I
tend to design libraries to be ignorant of their caller, and just do their
own job. Is there something specific you want to do differently? As a
different design (such as passing in some kind of service interface) may
be more appropriate.

Marc

Sep 21 '06 #3

P: n/a
"Jean Paul Mertens" <ON****@newsgroups.nospamschrieb:
I use a lib class to handle all my exeption errors ocured in my objects.
Since my objects are used in windows applications as well as in web
applications, I would like to determine in my lib class if she is serving
a web or a windows application. Is there a neat way to detect this.
Check out 'System.Reflection.Assembly.GetEntryAssembly'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Sep 21 '06 #4

P: n/a
In most scenarios this will do:

/// <value>Indicates that the application is running in ASP.NET</summary>

public static bool IsWeb

{

get {return System.Web.HttpContext.Current != null;}

}
--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]

"Jean Paul Mertens" <ON****@newsgroups.nospamwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
Hello to all,

I use a lib class to handle all my exeption errors ocured in my objects.
Since my objects are used in windows applications as well as in web
applications, I would like to determine in my lib class if she is serving
a web or a windows application. Is there a neat way to detect this.

Greets

Jean.Paul


Sep 21 '06 #5

P: n/a
In my view, library functions (except for explicit UI libraries such as
System.Windows.Forms) should never attempt to communicate with the user, and
the need to do so is a design confusion. Especially via MessageBox. The
calling UI itself should handle such things.

Reasons?
1: it makes the code hard to re-use and unreliable. Think of a service: it
isn't a web-app, but there is no user to talk to.
2: it can interrupt transactions causing blocking - e.g. if I create a
transaction, and then something goes wrong causing an error to be logged,
and *that* in turn does a MessageBox, and I have gone to get a coffee, then
the system could be leaving an open transaction, as until MessageBox
completes the code can't get back to the end of my transaction
3: it just makes too many assumptions about the environment, threading
model, etc

My advice: log it as you are, but then re-throw the exception all the way to
the UI, and simply have the UI catch this error and display accordingly.
This way, all "finally" and "using" blocks will have "done their thing"
*before* we start talking to the user.

If you *must* do this (perhaps to seek confirmation), then a service
interface may be helpful - but even this smacks of not passing enough
information to the method to let it do its job (or fail) completely;
thinking on the fly:

public interface IErrorService {
bool SupportsMessaging {get;}
MessageResult Message(....); // think "DialogResult", but without winforms
dependency
}

Then your WinForm and Web app can provide an IErrorService instance (with
the web not supporting messages, and the win supporting it and implementing
via MessageBox.Show; you could even use the IServiceProvider approach,
perhaps as a settable property on a static class, to avoid having to pass
around lots of services.

Marc
Sep 21 '06 #6

P: n/a
Marc,

Indeed, I let mij lib log the exeption and I retrow it to my UI with the
correct errormessage combining all possible errors that ocured. In the lib I
put the different ways to display it to my users in different static
functions. If I then use my dataobject I can decide in the upper-application
what way to use to prevent the user from what is going on.

tnx to all,

Jean Paul

"Marc Gravell" <ma**********@gmail.comschreef in bericht
news:OR**************@TK2MSFTNGP03.phx.gbl...
In my view, library functions (except for explicit UI libraries such as
System.Windows.Forms) should never attempt to communicate with the user,
and the need to do so is a design confusion. Especially via MessageBox.
The calling UI itself should handle such things.

Reasons?
1: it makes the code hard to re-use and unreliable. Think of a service: it
isn't a web-app, but there is no user to talk to.
2: it can interrupt transactions causing blocking - e.g. if I create a
transaction, and then something goes wrong causing an error to be logged,
and *that* in turn does a MessageBox, and I have gone to get a coffee,
then the system could be leaving an open transaction, as until MessageBox
completes the code can't get back to the end of my transaction
3: it just makes too many assumptions about the environment, threading
model, etc

My advice: log it as you are, but then re-throw the exception all the way
to the UI, and simply have the UI catch this error and display
accordingly. This way, all "finally" and "using" blocks will have "done
their thing" *before* we start talking to the user.

If you *must* do this (perhaps to seek confirmation), then a service
interface may be helpful - but even this smacks of not passing enough
information to the method to let it do its job (or fail) completely;
thinking on the fly:

public interface IErrorService {
bool SupportsMessaging {get;}
MessageResult Message(....); // think "DialogResult", but without
winforms dependency
}

Then your WinForm and Web app can provide an IErrorService instance (with
the web not supporting messages, and the win supporting it and
implementing via MessageBox.Show; you could even use the IServiceProvider
approach, perhaps as a settable property on a static class, to avoid
having to pass around lots of services.

Marc


Sep 21 '06 #7

P: n/a
PS

"Jean Paul Mertens" <ON****@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Marc,

Indeed, I let mij lib log the exeption and I retrow it to my UI with the
correct errormessage combining all possible errors that ocured. In the lib
I put the different ways to display it to my users in different static
functions. If I then use my dataobject I can decide in the
upper-application what way to use to prevent the user from what is going
on.
Seems like a code smell to me. You have one big exception handler object
that you are using a switch statement in. You should have a WinForms
exception handler and a WebApp exception handler. Only one of these
exception handlers will ever register to listen for exceptions and then do
it's stuff when needed.

PS

>
tnx to all,

Jean Paul

"Marc Gravell" <ma**********@gmail.comschreef in bericht
news:OR**************@TK2MSFTNGP03.phx.gbl...
>In my view, library functions (except for explicit UI libraries such as
System.Windows.Forms) should never attempt to communicate with the user,
and the need to do so is a design confusion. Especially via MessageBox.
The calling UI itself should handle such things.

Reasons?
1: it makes the code hard to re-use and unreliable. Think of a service:
it isn't a web-app, but there is no user to talk to.
2: it can interrupt transactions causing blocking - e.g. if I create a
transaction, and then something goes wrong causing an error to be logged,
and *that* in turn does a MessageBox, and I have gone to get a coffee,
then the system could be leaving an open transaction, as until MessageBox
completes the code can't get back to the end of my transaction
3: it just makes too many assumptions about the environment, threading
model, etc

My advice: log it as you are, but then re-throw the exception all the way
to the UI, and simply have the UI catch this error and display
accordingly. This way, all "finally" and "using" blocks will have "done
their thing" *before* we start talking to the user.

If you *must* do this (perhaps to seek confirmation), then a service
interface may be helpful - but even this smacks of not passing enough
information to the method to let it do its job (or fail) completely;
thinking on the fly:

public interface IErrorService {
bool SupportsMessaging {get;}
MessageResult Message(....); // think "DialogResult", but without
winforms dependency
}

Then your WinForm and Web app can provide an IErrorService instance (with
the web not supporting messages, and the win supporting it and
implementing via MessageBox.Show; you could even use the IServiceProvider
approach, perhaps as a settable property on a static class, to avoid
having to pass around lots of services.

Marc


Sep 21 '06 #8

P: n/a
I agree with this one. (aka, Eliyahu's)

I use this one fairly often.

Keep in mind which namespace/assembly its in.
PS

You normally dont' need to post to 4 or more groups.


"Eliyahu Goldin" <RE**************************@mMvVpPsS.orgwrote in
message news:eG**************@TK2MSFTNGP03.phx.gbl...
In most scenarios this will do:

/// <value>Indicates that the application is running in ASP.NET</summary>

public static bool IsWeb

{

get {return System.Web.HttpContext.Current != null;}

}
--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]

"Jean Paul Mertens" <ON****@newsgroups.nospamwrote in message
news:%2******************@TK2MSFTNGP03.phx.gbl...
Hello to all,

I use a lib class to handle all my exeption errors ocured in my objects.
Since my objects are used in windows applications as well as in web
applications, I would like to determine in my lib class if she is
serving
a web or a windows application. Is there a neat way to detect this.

Greets

Jean.Paul


Sep 22 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.