HttpContext

  • Thread starter Thread starter Peter K
  • Start date Start date
P

Peter K

Hi

I am using a 3rd party library in my web-app.

Now I wish to write some simple "console-apps" for testing certain bits of
functionality in my program - where I can simply enter some parameters and
see that my program successfully fetches the correct data for example.

But I have discovered that the 3rd party library I am using uses
HttpContext.Current.Session - which doesn't exist in my console-app. Can I
"fake" it somehow?

Thanks,
Peter
 
Peter K said:
Hi

I am using a 3rd party library in my web-app.

Now I wish to write some simple "console-apps" for testing certain bits of
functionality in my program - where I can simply enter some parameters and
see that my program successfully fetches the correct data for example.

But I have discovered that the 3rd party library I am using uses
HttpContext.Current.Session - which doesn't exist in my console-app. Can I
"fake" it somehow?
Click to expand...

Anything is possible. The problem with the approach you want to take is you
are going to a spend a great deal of time building up the bits you need.

My suggestion, for this one, is set up a simple one page web application
rather than a console app to test your functionality.

It really bugs me to see libraries this tightly coupled. Ugh!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

********************************************************
| Think outside the box!
|
********************************************************
 
Cowboy (Gregory A. Beamer) said:
Anything is possible. The problem with the approach you want to take is
you are going to a spend a great deal of time building up the bits you
need.

My suggestion, for this one, is set up a simple one page web application
rather than a console app to test your functionality.
Click to expand...

Yes, I think I will then.
It really bugs me to see libraries this tightly coupled. Ugh!
Click to expand...

Well, I guess it kind of depends. This code was designed only to run in a
web-context really. How could it have been done better, when they want to
share things in the current session? Made a wrapper to the session to use as
the common store, and used configuration to tell them to use that particular
wrapper/common storage?


/Peter
 
Peter said:
I am using a 3rd party library in my web-app.

Now I wish to write some simple "console-apps" for testing certain bits of
functionality in my program - where I can simply enter some parameters and
see that my program successfully fetches the correct data for example.

But I have discovered that the 3rd party library I am using uses
HttpContext.Current.Session - which doesn't exist in my console-app. Can I
"fake" it somehow?
Click to expand...

I think you should test the code running hosted within IIS. Otherwise
the test may not be worth much.

Arne
 
Peter K said:
Well, I guess it kind of depends. This code was designed only to run in a
web-context really. How could it have been done better, when they want to
share things in the current session? Made a wrapper to the session to use
as the common store, and used configuration to tell them to use that
particular wrapper/common storage?
Click to expand...

You can have something like this to make it easier for non-technical users:

public void RunSomeProcess()
{
HttpContext context;
//Get context from session here
RunSomeProcess(context);
}

public void RunSomeProcess(HttpContext context)
{
//Run process here
}

But to only leave the non parameterized version is asking for issues, as it
leaves you with no way to uncouple the library from the UI.

BTW, this is extremely common and comes from the fact that many developers,
when asked the question "What kind of apps are you building?" answer
ASP.NET, ASP.NET MVC, WPF, Windows Forms or Silverlight. When you think of
the UI as an application, you end up coupling more often than not.

When you start thinking of libraries as the app, or framework, you start
thinking about removing the tight coupling by providing another way.

To put this in perspective, I recently built a library to create short urls
from various sites. The signatures look like this:

public string ShortenUrl(string longUrl, string apiUrl, ICommunicator
communicator, string userName, string password)
{
}

I am passing in the communicator as ICommunicator. This provides two quick
benefits:

1. I can test using mocks
2. I am not tightly coupled to a particular communicator

A bit different than what you are talking about, as the coupling is directly
to the UI, but it is the same idea.

Now, how can you potentially solve your issue? Duplicate the HTTP context or
bind your application to the IIS process somehow. Not ideal, but these are
the cards you were dealt with.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

********************************************************
| Think outside the box! |
********************************************************
 
Back
Top