I'm working on a .net web app project where we develop on our personal machines, but our testing and production environments are in a corporate intranet. The problem is I run into bugs that only present in the testing/production environment, but not in dev. I find this makes it really difficult to track down the cause of the problem.

Are there any tips/strategies to deal with this issue?

**Please note I have no control or options when it comes to setting up new servers or modifying the test environment. I can only make changes to my local machine. I also do not have access to a company image file to image my PC.

1 Answer 1


Here are a few ideas:

If it is possible to get additional hardware or machines, here are a couple of ideas:

  1. Get a development server that is a mirror of the test server. This will provide a way to test functionality on a server rather than on developer's machines to ensure that functionality that may require configuration is picked up properly. Using Continuous Integration here can also be a useful tool in verifying bug fixes and preventing regression if developers keep making appropriate tests.

  2. Ensure developers have a separate machine, possibly virtually, so that tests can be done over a network rather than everything being done locally. This is where it can be handy to have older PCs that may be similar to client machines that can be used to test in various browsers on a machine separate from the intended server. This may not always be do able but it is something to suggest.

If not, here are a few other ideas to consider:

  1. While you develop on your personal machines, are you using IIS or Visual Studio's built-in web server to run your code? There can be differences here worth noting and is something to consider in going from one environment to another. This is where it can be important to have standards for the developers and ensure everyone understands why things are this way.

  2. Add additional debug information that may be useful in dev and testing environments that is turned off in production as it could well harm the performance. This would be where you could log exceptions with additional information or add informational messages about the state of the server since it is possible that App_pool recycling or other IIS settings could be what is triggering bugs that wouldn't easily be caught by developers that often restart their own App_pool to reflect code changes. In a sense, you want to have some performance counters in the code that log values at regular intervals that may help diagnose issues as there can be issues with heavy load that could harm an app that is different than what developers may initially test within their code.

  3. Log the differences in environments. Multiple servers? Firewalls? Load balancing? Versions of software? Ensuring patches are up to date on all the servers? While this is a menial task on one level, maintaining a document that shows differences could be quite useful as if you develop on IIS 7.5 and deploy to IIS 5.0 then there may be some differences that could be an issue.

  4. Consider what kinds of tests do you have on your environments. Are there load tests? Are there penetration tests? This can be something to explore though depending on the issues being found it may or may not be easy to justify the costs for some of the higher-end tools.

  • These are all really good suggestions, but unfortunately I have no control over servers, etc. The only thing I could look at is using IIS instead of the built in web server.
    – Legion
    Jul 4, 2013 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.