Debugging irregularities

I am using Unity 2017.1.0b10 and Visual Studio Enterprise 2017.

When I use the debug version of my dll, there are a number of problems compared to Unity 5.6.1.f1.

1. When I add the pdb and unity generates the mdb files to debug a dll project, the callstack does not match the execution line and/or breakpoint hit.
1.a. On a breakpoint, I am unable to see what the value is for any class member or parameter to a method
2. I am getting a NullReferenceException on a property when I stop the editor:
NullReferenceException: Object reference not set to an instance of an object
SBM.DependencyInjection.Context.ProjectContext.OnDestroy () (at F:/Repos/SuperBitMachine/sbmcore/SBMCore/SBMCore/DependencyInjection/Containers/BindCondition.cs:9)

I am doing my custom version of Dependency Injection. When I look at line 9 in BindCondition, its this:

Code (CSharp):

1.  
2.         public object[] Parameters { get { return _parameters; } }
3.  

The other weird thing is that ProjectContext.OnDestroy() has no knowledge of what IBindCondition is, nor what the Parameters property is:

Code (CSharp):

1.         private void OnDestroy()
2.         {
3.             _logger.Log("Project Context Cleanup");
4.  
5.             if (_container != null)
6.                 _container.Dispose();
7.  
8.             if (_instance != null)
9.                 Destroy(_instance.gameObject);
10.  
11.             _readySignal = null;
12.             _instance = null;
13.             _container = null;
14.  
15.             GC.Collect();
16.         }

It seems as if my .dll is being load as Release version, but I am assured, that I am build the Debug version.

 

Using the forum for bug-reporting isn't the best way to report an issue that is important to you, but can be used to give it a little more attention.

If you found an error in Unity, I recommend to submit a bug-report following the advice in this document. Using the bug-reporter seems to be an important step, because that makes sure the report is in their bug-tracking pipeline and has to be processed at some point.

It's advantageous to attach a project to the bug-report that Unity can use to reproduce the issue and test their fix against.

From my experience, Unity prefers to get spoon-fed with a small project that they can use to easily reproduce the issue you're reporting, along with a how-to-reproduce list in baby-steps. I often record a video that shows how to reproduce the issue with the project I submit along with the bug-report, just to make sure to avoid any ambiguity. Depending on the complexity of the issue, a video might not be necessary.

The easier an issue can be reproduced by QA, the more likely it is to get forwarded to a developer, who might or might not work on a bug-fix for that at some point.

After you submitted the bug-report, you receive a confirmation email with a Case number. Unity often asks us to post the Case number in the forum thread, which allows them to find that bug-report if they look at your post.

Following these steps will increase the chance that Unity is looking at your issue tremendously.

 

So I figured out the problem. I was compiling my dll against beta 4 not 10.

For people who read this in the future, In VS, look at the reference to UnityEngine.dll make sure the path and/or version matches the version of of Unity you are targeting.