Last post Jun 21, 2017 11:10 AM by PatriceSc
Jun 19, 2017 03:40 PM|Ken Carter|LINK
Well came in to a lovely situation this morning. Over the weekend our network team killed a two way trust between our corporate domain and our newly created subsidiary domain. This was planned just not planned very well. Prior to the cut over I had created
accounts and duplicated rights as much as I could for the new accounts in the new domain. The servers had all been transferred into the new domain a few weeks back and this weekend they cut off the two way trust between the new domain and the corporate domain
(which was the end goal). The web apps in question had worked fine housed on the new domain and users were able to use it just fine. It felt like we were prepared to cut off the trust as we no longer needed the accounts on the corporate domain to log into
the web apps. This morning proved otherwise:
Server Error in '/CInTRAC' Application.
Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[NullReferenceException: Object reference not set to an instance of an object.]
CInTrac.SiteMaster.Page_Load(Object sender, EventArgs e) in C:\Users\B18833\Documents\Visual Studio 2015\Projects\CInTrac\CInTrac\Site.Master.cs:28
System.Web.UI.Control.OnLoad(EventArgs e) +108
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1435
I'm interpreting this as the next best thing to a 'File Not Found' related to the master page for the site which is Site.Master. What is a bit baffling is that Site.Master is clearly in the folder with the web app:
I don't believe this is an authentication issue, but rather appears to be a permissions issue maybe where IIS can't see the file based on the permissions. But as I review it I don't see where this can be the case.
Anyone else deal with this in a domain migration, or have any insight that could help come to a resolution on this one?
Jun 19, 2017 03:56 PM|PatriceSc|LINK
It seems to happen rather inside the Page_Load code for your SiteMaster page. Have you tried to check this code for a NullReferenceException (it means that you attempt to access an object member while the object is still null).
Jun 19, 2017 04:17 PM|Ken Carter|LINK
Since the domain cut over my web deploy hasn't been successful on the dev box. I have a fully tested local update to one of my apps that is ready to be published but when I went to test it on the dev/test box even though I had zero errors in the web deploy
process (direct and file based) the app wouldn't come up.
So, if I were to change anything on the production boxes code and attempt to publish I would expect the same results (dead app).
Logic suggests to me (if I am not missing anything) that if the only thing that changed this weekend were network based and not my servers or web apps, modification of my web apps code 'should not be necessary'.
I'm not depreciating your suggestion, I'm only concerned that if I attempt a republish of this (which runs locally just fine) it will break what was (Friday night) a working app further. There surely is something that allowed it to function fine last week
that has been changed and requires a modification outside of code to correct now. I just don't know what that may be.
Jun 19, 2017 05:16 PM|PatriceSc|LINK
I'm not suggesting any fix or that a code change and publishing the app again will be needed. For now I'm just trying to understand the EXACT problem you have.
To me the problem is not that this file is not found. As the stack trace starts with CInTrac.SiteMaster.Page_Load the SiteMaster class is loaded and its Page_Load method is called. Then in this Page_Load method you are trying to use an object
member while the object is still null.
Then only we'll see if a config change is enough or if the code needs to be fixed. For example it could be a search in the old AD and you need to change the web.config file to lookup for user details in another domain or you'll need a code change if the
domain name was hardcoded. But then as you said you may want to investigate further as it seems you perhaps have some other issues as well with this change.
But once again for now I'm just trying to get at the *exact* problem rather than trying to guess.
Jun 20, 2017 03:44 PM|Ken Carter|LINK
Well the network guys did me wrong AGAIN!! The opened the trust back up again and of course now the apps work again. As a result, I can't really trouble shoot this effectively with it working. When they reset shut down the two way trust later (they have
to accomplish this due to regs) I will take the information you've provided here and attack it again. ... and consequently update you with what my findings are at that time.
Jun 21, 2017 08:30 AM|EvenMa|LINK
Hi Ken Carter,
According to your description, the domain trust had been changed, and then there had some error with your site.
Could you show the code which occurred the exception for us to find out the issue exactly?
Might there had some error when you access the domain after the trust had been removed.
If you have any other questions, please feel free to contact me any time.
Jun 21, 2017 11:10 AM|PatriceSc|LINK
You can still have a look at the code found in the Page_Load event of your SiteMaster page (and maybe post that if you don't have too much code). And so it seems this kind of change results in trying to use an object which is null rather than properly initialized
inside this CInTrac.SiteMaster.Page_Load method...