1

I (recently inherited) a asp.net web application in production. After fixing a generic bug in the area of making a table selection - we have a problem regarding security policies not allowing access to a certain active x plugin.

Our client is reluctant to allow permissions (this has fixed the problem on our test environment). They persist that this was not necessary before deployment of our supposed fix, and that it should not be necessary for them to change their security settings, as it was working fine before the deployment of the fix.

The fix really have nothing to do with permissions, and of course now we would like to better understand the problem, before making a decision of what to do next.

I am thinking that maybe it has something to do with build parameters, such as compiler versions used. Or that it might have something to do with environmental settings (64 bit vs 32 bit).

I have no idea of where to start, or what to compare. Is there a tool that can be used to compare compiler settings used to create a dll? (the changes was in a dll).

closed as off-topic by Thomas Owens Sep 21 '16 at 15:17

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to find or recommend tools, libraries, programming languages, resources (including books, blogs, tutorials, and examples), or projects to undertake are off-topic here as they attract opinionated answers that won't have lasting value to others. You may be able to get help in The Whiteboard, our chat room." – Thomas Owens
If this question can be reworded to fit the rules in the help center, please edit the question.

  • I feel like there might be a StackOverflow question here. Is there any way to post the error or exception that you are getting, and give a high level description of the changes? – Greg Burghardt Jun 23 '16 at 12:54
0

Our client is reluctant to allow permissions ...

As it their right.
You have no mandate to be dictating the security settings that your client "has" to use.

... this has fixed the problem on our test environment

Wrong!
This has only masked the problem because the problem still exists at your client's site and, let's face it, that's the only place that matters.

You must have a representative testing environment, i.e. the same as your client[s] site[s], or your tests are practically worthless.

They persist that this was not necessary before deployment of our supposed fix ...

"Supposed fix". Interesting turn of phrase. Or, perhaps, a realisation that your change wasn't the right thing to do.

... and that it should not be necessary for them to change their security settings ...

And they are absolutely right.

You've made a code change that rectifies the reported defect (about table selection) but have introduced a new defect whereby your code does not conform to the client's chosen security settings.

The fix really have nothing to do with permissions

Possibly not, but it's introduced a new defect that clearly does.

we would like to better understand the problem, before making a decision of what to do next.

You don't have much of a decision to make.

Find another fix for the table selection problem that the client is happy to accept.

I am thinking that maybe it has something to do with build parameters, such as compiler versions used. Or that it might have something to do with environmental settings (64 bit vs 32 bit).

No; I would look at that ActiveX Control first.

Did you introduce this control as part of the table selection "fix"? If so, that's almost certainly your problem. If it was there before the "fix", then you have other problems.

I have no idea of where to start, or what to compare.

You don't use a Source Control tool to record all changes made to your source code? Project Files?

Is there a tool that can be used to compare compiler settings used to create a dll? (the changes was in a dll).

Practically every Source Control product on the planet comes with some sort of version comparison tool.

If you're not using them, then you really are flying by the seat of your pants.

  • 1
    I am a software developer for +/- 15 years, working in a professional environment on products that are actually used every day; not someone who just started programming and still need to learn the basics. Of course we have version control and other best practices. In all your sarcastic commentary there is not one piece of sound advice that I can take with me to try and solve the problem. I hate when people just comment on questions to get their own stats up, offering very little help but to aggravate and stir. Stack is becoming more and more a training ground for such type of behavior. – Harriet May 24 '16 at 11:39
  • If you have version control, then you can compare compiler settings, because you manage the project & build files. Double-check that it's not something that's changed at the client site. Install your "previous" release on a clean, client-site machine. If it exhibits the same problem, something's changed "Out There". If not, then it's something that you changed. Use Source Control to find out what. – Phill W. May 25 '16 at 10:48

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