1

I think I am getting tunnel vision here and maybe I haven't had enough coffee, but I've put a simple change into one of the code behind files for my ASP.Net website (hosted on Windows Server 2008 R2) and recompiled the entire solution. I then grab the DLL compiled from the project containing the code behind in question and replace the old one on the server so that my changes will take effect (changed from a 16 bit integer to a 32 bit) and the changes do not seem to be reflected even after the following:

  • Replace old DLL with the new version.
    • Replaced in the bin folder of the website.
  • Recycled app pool.
  • Restarted website.
  • Restarted IIS (don't like doing this).
  • Inspected Temporary ASP.Net Files in the Windows Directory
    • There are several copies of the same DLL in there, but I don't believe it is a good idea to remove them as I'm not the only user.
  • Cleared my cache.
  • Checked the GAC.
    • Nothing here either, but I knew that was a long shot.
  • Changed the version number on the DLL.

The changes still aren't being reflected and it has me wondering:

  • Is the code behind for a page placed into the DLL of the containing project?
  • If so, then where else should I be looking to replace the DLL?
Hazel へいぜる
  • 2,751
  • 1
  • 12
  • 44
  • 1
    Is there a reason you can’t replace all site files? Are you using `CodeBehind` or `CodeFile`? What happens if you bump the DLL’s version number and output it to the page somewhere to make sure? – Dai Apr 19 '19 at 15:00
  • 1
    @Dai The current state of the solution includes changes that cannot be released until next month, but there is an issue that needs to be resolved this week so I am unable to perform a complete publish (I haven't had the chance to set up branching and merging yet). I am using a `CodeBehind`, and give me a moment to test bumping the version number (I believe this will case an error though due to change in signature perhaps). – Hazel へいぜる Apr 19 '19 at 15:02
  • Did you check the timestamp of the dll to make sure it is the latest? Often issue like this occur when you have in your project bin folder a Debug and Release Version. Then compile/install the wrong version. – jdweng Apr 19 '19 at 15:04
  • @jdweng The `DLL` on the server is definitely the latest version via timestamp. Configuration is set to test currently as I am still testing the deployment of the change. The hotfix is currently being applied to the test server, then production. – Hazel へいぜる Apr 19 '19 at 15:05
  • 2
    @PerpetualJ Off-topic: but it sounds like your organisation isn't using source-control and continuous-deployment correctly because then you could branch-off whatever your `publish` branch is to make the fix without introducing other changes that would be in separate feature branches. – Dai Apr 19 '19 at 15:06
  • @Dai I just took over on this and it is indeed a mess; I have to slowly get it up to standards. – Hazel へいぜる Apr 19 '19 at 15:07
  • @Dai changing the version numbers didn't help either. Still not picking up the changes. – Hazel へいぜる Apr 19 '19 at 15:08
  • As you're asking for a hotfix, then I don't know whether I should comment this, but still: Can you make a copy of your application, and then make the required changes that you want, and after building your solution, host this application in IIS. That way you can be certain, that your bits are working fine. Because I think the particular dll you're replacing is not the one which should be replaced. Or I think I'm assuming too much :/ – TejasGondalia Apr 19 '19 at 15:18
  • @BeginnerTejas I know that if I publish the solution to the server (did this in the sandbox server), it picks up my changes. However, since this is a hot-fix, I want to ensure the deployment method of the DLL is exactly the same in test as it will be to push it to the production environment. My biggest question, is what am I missing; I've even checked the GAC which I knew was a long shot, and of course it wasn't there. Rolling out all of the other changes with a new branch would be a very tedious process with the current state of the website. It's quite fragile currently. – Hazel へいぜる Apr 19 '19 at 15:22
  • what type of file it was in which you made the code change? .cs,.aspx? Or there were more than one? – TejasGondalia Apr 19 '19 at 15:27
  • @BeginnerTejas A single `.cs` file was changed on two lines. This file is the code behind for a `.aspx` file but the `.aspx` was not changed. – Hazel へいぜる Apr 19 '19 at 15:31
  • It's just a guess and I don't know how to put this, but still bare with me: As our project may contain more than one .cs file, and the way one .cs file talks with the other one after making the change is loading each other's assemblies once again when we build the solution. Suppose you have ProgramOne.cs file and another is ProgramTwo.cs file and both have each other's references by including using namespaces or something. Suppose your change is only in ProgramOne.cs. But if you don't build your solution, then ProgramTwo.cs won't reload the assembly of ProgramOne.cs in it's dll. – TejasGondalia Apr 19 '19 at 15:44
  • So along with ProgramOne.cs, your ProgramTwo.cs also needs to be recompiled if it has a reference/dependency on it even if the change is just in the former one. But still, I accept that's a vague explanation. But you can still check this. If your dll needs to be reloaded in any other dll/file. – TejasGondalia Apr 19 '19 at 15:47

0 Answers0