Moq4 compiled in debug mode?

[kendallb]

Hi Guys,

I am having issues with Moq4 as I recently moved up to it from Moq3 via NuGet, but it appears the NuGet package was compiled with debugging turned on so Visual Studio keeps trying to find the source files under the c:\projects\moq4 directory, which of course I do not have.

This is extremely annoying when trying to debug unit tests, so is there a way to turn this off or can the project be compiled in release mode with debugging information so it works the way it used to?

Someone suggested enabling Just My Code but I already have this enabled.

[stakx]

@kendallb: Moq is compiled in release mode. But it has debug symbols included.

I'm starting to see that introducing SourceLink may have been premature, simply because not everyone is using the latest, required tools yet. The included debug symbols are indeed somewhat of a pain if you're not using Visual Studio 2017, i.e. if your version of Visual Studio does not yet have support for SourceLink.

Instead of SourceLink, Moq was once upon a time set up to use GitLink (which, instead of including a mapping description between file names and GitHub URLs, actually replaces the file names in the PDB with GitHub URLs), but apparently that was abandoned since it was never successfully tested to work as expected. @kzu did mention in #170 that he would welcome the switch to SourceLink... so that's what I did.

We have several ways to deal with this (ordered from "state of the art" to "how it was done in the good old days"):

• See whether we're doing something wrong that others using SourceLink get right. AFAIK, e.g. xUnit.NET also distributes SourceLink-ed PDBs in their NuGet packages, so we could check whether they're doing something differently than Moq. (Are we perhaps missing attributes on methods such as [DebuggerNonUserCode], etc.?)
• Switch back to GitLink, i.e. replace the file paths in the PDB with GitHub URLs. This would likely solve the problem you're observing for some previous versions of Visual Studio. (But know that GitLink might eventually merge into, or be abandoned because of, SourceLink.)
• Distribute PDBs as a separate symbols package.
• Remove the debug symbols again and never add them back.

[stakx]

(Btw., as a quick hacky fix, you can just delete the Moq.pdb file locally, e.g. via a post-build event script.)

[kendallb]

Thanks, I will delete the .pdb file that now from our packages directory.

From my opinion I wonder what the true value is of having source level debugging for a library like Moq (or the tools is relies on like Castle). When debugging a unit test the last thing I really need to be doing is caring about the Moq internals. Sometimes I do care about the internals of projects I rely on and if they have source code on GitHub I simply compile from source and debug that. If there was a way to do source level debugging only when you need it, that would be better.

I am not familiar with how SourceLink works and if it would support that for VS2017 or not. We have not yet moved to 2017 and plan to do so soon, but until recently some of the plugins we use did not yet support it.

[stakx]

@kendallb: Visual Studio 2017 has good support for SourceLink, and you can stop the VS debugger from stepping into Moq's source code (or other third-party code) by enabling both the "Enable source link support" and "Just My Code" options I mentioned earlier. So upgrading to VS 2017 would solve this problem for you.

But I hear you. For people who haven't yet upgraded, I admit that the SourceLinked PDBs are perhaps a bad thing (even though some people are very enthusiastic about them). I'll open an issue over at ctaggart/SourceLink to ask for advice on this.

[kendallb]

Yeah sounds like the way VS2017 does it is clean, in that I would only debug into Moq if I turn off Just My Code. Sounds like I need to pull trigger on VS2017 soon :)

Nuking the PDB files worked fine also so I am doing that for the time being. We check the package files into Git ourselves anyway so we can make sure everyone has exactly what is needed so that will be a good solution until we move to VS2017.

[stakx]

Good to hear you've found a workable solution for the time being. Let's keep this issue open anyway. I've asked for advice on this (see linked issue above), perhaps we can still do something clean even for pre-VS2017 users.

[stakx]

@kendallb, which version of Visual Studio are you using?

I ran a test with Visual Studio 2015 Update 3 (version 14.0.25431.01), where the debugger setting "Enable Just My Code" works fine. When activated, VS will not step into Moq's source code; if Moq throws an exception, the debugger will break in your code, not somewhere inside Moq's. In the Output window, you'll see a message:

Loaded '…\Moq.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

Are you using a VS version older than Visual Studio 2015 Update 3?

[kendallb]

I am using update 3. It is not moq specifically but the castle proxy. To trigger the issue you need to set up a mock with CallBase set to true and then mock a virtual function on the class and call a function on the class that then calls that mock. When you try to step into the function (perhaps to debug a mock callback) or just call a virtual function itself it wants to let you step into the code.

I would be happy to build a sample project showing the issue if you wish.

[stakx]

@kendallb:

I tried to put together repro code based on your description (see code below), but VS debugging worked flawlessly with "Just My Code" enabled.

I would be happy to build a sample project showing the issue if you wish.

That would be great, please do. 👍

// This code does NOT reproduce the reported debugging problem in VS 2013 Update 3
// with "Just My Code" enabled.

static void Main()
{
    var mock = new Mock<Class>() { CallBase = true };
    mock.Setup(m => m.VirtualFunction()).Callback(() =>
    {
        Console.WriteLine("Mock callback for VirtualFunction invoked.");
    });
    mock.Object.Do();
}

public class Class
{
    public void Do() => this.VirtualFunction();
    public virtual void VirtualFunction() => Console.WriteLine("VirtualFunction invoked.");
}

[stakx]

@kendallb:

I would be happy to build a sample project showing the issue if you wish.

Just a friendly ping. Any progress on the sample project yet?

[stakx]

Closing this due to inactivity. If you do get around to looking into this again, please just post back here and we can continue this.

[kendallb]

Sorry yeah been busy rolling into Black Friday. I will find some time this week to create the solution and post it.

[stakx]

OK, cheers. All the best with your business until then.

[kzu]

FWIW, I'm firmly on this camp for things like this: https://medium.com/@mikeal/stop-supporting-old-releases-70cfa0e04b0c

If this is really important for you, and migrating to the latest and greatest VS isn't an option, a PR is the best route.

[kendallb]

Sorry I have not gotten back to this. I will try to find time tomorrow. I have VS2017 installed but have two major problems. The PHP tool we use does not yet support it (they are trying to figure out why it crashes at the moment), and with our main project it is much slower than 2015 for some reason. Gah. I do hope to move to it fully soon and I am also trying Rider. Be interesting to see if it has the same issue.

[stakx]

@kendallb - I'm having issues with VS 2017 at the office, too., so yes—transitioning fully to the latest VS version can take too long. :-) If you do find the time to look into this issue, that's appreciated, but there's no rush. Btw. don't be confused by the tagging. Just cleaning up and re-tagging the backlog.

[stakx]

in Moq 4.11.0-rc2 we switched to a separate debug symbols package, i.e. the PDB files are no longer included in the main package, so being able to step into Moq's source code is now more of an opt-in feature than before. See https://github.com/moq/moq4/blob/v4.11.0-rc2/CHANGELOG.md#changed.