I have a very unusual problem. I have an ASP.NET application that uses LINQ-to-SQL a lot, and works fine on most servers. However the application exists on another server on the same network, and after a recent update, whenever I open a new DataContext like this:
LINQDataContext dc = new LINQDataContext();
The dc object is null, so I get object reference errors trying to use it. I cannot replicate this on my development machine, or on the other server which the application exists on, so I'm baffled about why this could be. Any ideas?
Since you are using default constructor of your DataContext, then connection string is read from web.config. So we could make a suggestion that application on that server has different config without proper connection string. But there is one more thing that we've faced once in our project. In a new version of ASP location of connection string storage in config file has changed. I don't have code at my fingertips, but you could test my suggestion by using constructor that takes connection string as a parameter. Read connection string from config manually or just hardcode it for testing purpose.
Something like this can't happen. When you call the new operator on a standard .Net type, there are two possible outcomes:
the constructor returns normally and the value is assigned
the constructor throws an exception, the value is not assigned
Unless you catch the exception right away, and ignore it, you can be sure that the variable has been assigned. This means your problem probably lies somewhere else.
(Technically, there is a third option – the constructor never returns and loops infinitely, but that's not relevant here.)
Related
I have the following code. The CustomControlHelper generates an instance of an object via reflection. At this stage we don't know what type of object we are dealing with. We do know it will be a CustomControl, but we don't know if it implements any particular interface or if it extends any other classes. The following code is trying to establish whether the loaded control implements the IRichAdminCustomControl interface.
Object obj = CustomControlHelper.GetControl(cc.Id, cc.ControlClass);
if(obj != null)
{
bool isWhatWeWant = (obj is IRichAdminCustomControl);
return isWhatWeWant;
}
That's all fine, but I've noticed that when I know I have an object that implements IRichAdminCustomControl, the expression evaluates to false.
Okay, this is where it gets really weird. If I inspect the code when debugging, the expression evaluates to true, but then if I immediately let the code run and inspect the result, it evaluates to false (I've attached an animated gif below to illustrate).
Has anyone come across weirdness like this before and if so, what on earth is causing it?
Incidentally, I believe the product I'm using uses Spring.NET to provide dependency injection in the CustomControlHelper.
If you are using Visual Studio 2010 SP1, I came across this bug:
Misreporting of variable values when debugging x64 code
There is a workaround on that page, posted by Microsoft:
You can either set all projects to compile to x86, or create an intermediate initialised variable declaration to ensure the debugger reports the correct value of the variable being examined.
Try this as a workaround:
bool isWhatWeWant = true;
isWhatWeWant &= (obj is IRichAdminCustomControl);
bool finalValue = isWhatWeWant; // this line should fix isWhatWeWant too in the debugger
return finalValue;
EDIT: seems like VS2012 also encounters similar problems in specific conditions.
Two possibilities come to mind. The first is that your interface name is generic enough that it could already be in the namespace somewhere. Try fully qualifying the interface in the is clause. The second possibility is that you might be running the code as part of a constructor, or being called indirectly by a constructor. Any reflection like stuff needs to be done after we are certain the application has fully loaded.
So I found the answer. It was because I had two copies of the dll in different locations. I had one copy in the bin of my back-end application and one in a shared external directory that gets dynamically loaded by the backend app.
I should explain; this application consists of two apps running in tandem, a frontend app and a backend app. Ordinarily, you place "Custom Controls" into your frontend app. These controls are then copied on application start to a external directory that is accessible to the backend app.
In this case, I had logic in my Custom Control library that needed to be accessed in the backend app - so I had to make a reference to it... which ended up with the backend app having two references to the same class. D'oh! And OF COURSE that's going to work when you're debugging.
Solution was to split my extra logic into its own project and reference THAT in the backend app.
I'm not going to "accept" my own answer here because, although it solved my specific problem, the solution is a bit TOO specific to the apps I'm working with and would be unlikely to help anyone else.
This happened to me once and even though I never came to a conclusion as to why it was happening I believed the PDB files that were being loaded with the debugging symbols where out of sync. So, by "cleaning" the solution and then rebuilding the solution this weird issue went away.
I know similar questions have been asked a million times. I've read them and I still cannot get to the bottom of this. I'm using the Novell.Directory.Ldap c# library in my code (Winforms, c#). It works very similar to the microsoft ldap libraries but it can also access the attributes specific to Novell eDirectory.
using Novell.Direcotry.Ldap; is in there. I also added the reference and pointed it to the Novell.Directory.Ldap.dll file.
string LDAPServerIP = "12.34.56.78";
string serverUserName = "cn=Rrunner,o=acme";
string serverPassword = "#nvi1";
LdapConnection ldapConn = new LdapConnection();
MessageBox.Show(ldapConn.ToString());
ldapConn.SecureSocketLayer = true;
ldapConn.Connect(LDAPServerIP, 636);
ldapConn.Bind(serverUserName, serverPassword);
I get a NullReferenceException when it gets to the ldapConn.Connect() method.
Stepping through in the debugger is can see the ldapConn object, and it is a Novell.Directory.Ldap.LdapConnection object and seems to have sensible values assigned to it. For example, it does get SSL set to true, and at the point of the exception it even has already had the Host(string) variable set to the LDAPServerIP, and the Port(int) set to 636 just as the ldapConn.Connect() ordered. Given this information, I put a try/catch on just that statement to get past it since it is putting the attribute in anyways. It then will also get the exception on the Bind() method, and bind did put the appropriate values (userDN and password) into the object as well.
That section of code I copied directly from another program I use/write and it works perfectly fine in that so I don't know why it shouldn't work in this program. The only difference is that this is a differnt project in Visual Studio.
Given that, I've tried going through the things again that could be different because its a different project:
I've tried verifying that the reference to the Novell supplied is in the project. I'm fairly certain that part must be working because the object in memory is of the correct type and has a bunch of attributes that my program doesn't tell it about so they had to come from that dll file.
The SSL cert exists on my computer in a spot where .net can find it as this is the same computer that I develop the program that does connect to LDAP successfully.
What am I misssing? It seems like it has to be something really simple.
I found it finally. It was something really simple, and something that had to be set due to being a different project. I needed to add Mono.Security.dll and the reference to it.
I'm using Entity Framework 5 in my project. And I wanted to test some new funcionalities.
What happened is that eventhough my db is UPDATED, (when I add a migration it does not add anything else) and eventhough if I run my project it runs just fine. When I try to test the project with NUNIT I get this exception:
System.InvalidOperationException : The model backing the 'DbContext' context has changed since the database was created. Consider using Code First Migrations to update the database
Has any of you have this problem? If so how can I solve it?
Well, my original answer got deleted, guess because it wasn't really an answer as much as a statement that I had the same problem. At this point I have found an answer of sorts, so maybe this one will pass muster.
Of course, I only assume we are having the same issue, but it seems pretty likely since the symptoms are exactly the same. What I discovered is the connection string for my repository was not getting set correctly even though I had set it up "correctly" in a config file using the MyTestProject.dll.config naming convention. Seems like NUnit isn't using the connection string from the config for some reason.
I've set up a temporary solution where I use a different constructor that forces the correct connection string for my repository when creating it for NUnit. Easy to implement this since I'm using DI to create the repository and just need to ask the factory for a different flavor when testing. Working now to figure out why NUnit doesn't use the config file as it seems like it should.
Maybe not a complete answer, but at least this solution got me back to where I can test... We'll see if this one gets deleted.
I’m learning my way around ASP.NET MVC using vs2010 and .NET4 – nothing for production use, just for my own personal use.
I created a default ASP.NET MVC which comes with pre-existing home page, about page and login and registration pages. In attempting to use the existing login and registration pages I (not having an SQL server) replaced the SQLMembershipProvider with the MySQLMembershipProvider found in Connector/NET in the MySQL.Web.Security.
However this didn’t work straight away, aside from the common issue people seemed to have with autogeneration of the schema (solved by googling) I had two other problems that I noticed.
The first was that if left unset or simply as an empty string, the PasswordStrengthRegularExpression would cause a Null Exception in the MySQLMembershipProvider. I solved that by modifying the providers code to fix the “if” statement where the problem was occurring. (If I recall, it was only checking that the string wasn’t empty, it didn’t check for the string being null)
The second was that the MySQLMembershipProvider has an Initialize method, overridden from the base class, which must be called on each instantiation of the provider. This method was being called only on the very first instantiation but not again afterwards (determined by stepping through the code and use of breakpoints). The provider appears to be instantiated once per page load.
My solution (not the best) has been to modify the MySQLMembershipProvider to create static variables to store the arguments of the call to Initialize and a variable to store whether or not the object has been initialized. I then put a call to the Initialize method at the beginning of every other method. The Initialize method was modified to return instantly if the object had already been initialized.
My query is this: Is the MySQLMembershipProvider flawed and thus the issues I’m describing are bugs or have I misunderstood something and not correctly used the MySQLMembershipProvider?
N.B. If you want to see code, please tell me which bits as 90% of it is auto generated or available from the mysql dev site as source. There is quite a lot.
So I got the dreaded "yellow screen of death"(? that's what the .NET guys called it) with the error message:
[NullReferenceException: Object reference not set to an instance of an object.]
OK, that's fine, I can understand that, but the error references a line of code which reads:
<namespace1>.<namespace2>.XMLDohickey responseXML =
new <namespace1>.<namespace2>.XMLDohickey();
(names obscured to protect the innocent (: ).
I can easily see how the line after, Session[<value>].ToString();, could cause this error, but I don't understand how the error could be caused by the line it claims to be caused by.
So, is it that C# is telling me the wrong line number, or can a namespace actually be null?
As a side note -- this seems to work fine locally, on my company's DEV and QA servers, but it seems like it failed on our client's QA server...
EDIT
So... here's the deal.
Apparently, when .NET crashes, sometimes it returns the last successful line called instead of the line which actually held the error. In this case, the Session[<value>] was null (Why? No idea. that "Should never happen").
A namespace can never be null, it will never generate any runtime errors of any kind (in the way you are describing it). So your null reference is probably in Session[key].ToString(), or the constructor of XMLDoHickey. I would consider checking if the value in the session state exists before calling a method on it.
Are you sure the exception doesn't come from inside the XMLDohickey constructor?
You need to force a recompilation and probably also clear the temporary internet files.
THere are often mismatches in the line numbers and the actual instruction causing the exception when source and binaries get out of sync and this must be the case here since namespaces surely dont cause null reference exceptions :)