Code Inspection fails when 'bin' folder is not present

My endeavor to integrate the inspectcode.exe tool in our build process continues to produce some very weird behavior...

We had a solution with half a dozen or so projects up until now, all working correctly for the most part. Our build template fires inspectcode against the solution on the build server and we parse the resulting xml to produce build warnings and errors.

Yesterday, a coworker added a new MVC project to the solution, and the build process started generating hundreds (literally) of errors. Today, I finally managed to reproduce the issue on a brand new, simple project. For some odd reason, the tool gives errors if the referenced dlls are not in the default output folder.

What I did is:

  1. Create a new project/solution, by selecting the Web template from Visual Studio 2013 -> Empty project plus MVC references (by marking the checkbox). This creates the most basic MVC project possible without any default views etc.
  2. Run inspectcode against it, no errors
  3. Create a default controller by clicking on Controllers and selecting new Controller
  4. Run inspectcode against it, no errors
  5. Delete the bin/obj folders
  6. Run inspectcode against it, no errors
  7. Create a new view, by clicking on Views and selecting new View
  8. Run inspectcode against it, no errors
  9. Delete the bin/obj folders
  10. Run inspectcode against it:

     <Issue TypeId="CSharpErrors" File="ResharperCodeInspectionTest\Views\TestView.cshtml" Offset="10-16" Line="3" Message="Cannot resolve symbol 'Layout'" />

Going by what happened here, it seems to be a problem with cshtml files only. I added a controller class exactly to validade that, and it works even if the bin folder is not present, which I assume should be the correct behavior since the original references are still present in their respective nuget package folders. The problem only occurs on views, when the mvc references are not in the output folder.

When I discovered that this was the issue, I tried to compare the MVC csproj file with other, working projects in the solution, like our webapi project, but didn't see anything of interest: everything seemed to be the same, same version of the MVC framework, etc etc.

Then I thought that maybe inspectcode was using the project's 'OutputPath' msbuild property to look up these references, and decided to pass in a different value on the command line, like this:
inspectcode <pathToSolution> /no-swea /output=c:\out.xml /properties:OutputPath=bin2

I then renamed the default bin folder to 'bin2' but it still produced the exact same error.

This is unfortunatelly unnacceptable in our case, since our build process overrides the output path for the whole solution and sends it's outputs to a single folder. This is actually standard behavior on TFS, and our release process is based around that. I thought about excluding cshtml files from the inspection but this is a very poor solution since we will lose a lot of good information when developing. It feels like a bug to me because all the other projects (which are mostly class library projects and one web api project) do work perfectly in that scenario.

I think the bottomline is: why does inspectcode need the referenced dll files present in the output path to correctly inspect cshtml files? I've included this small solution I'm using to reproduce the problem. You can very easily make inspectcode generate the error by deleting the bin folder and running the tool against the solution.

I'd love to get at least some feedback on this since this is blocking our build process at the moment, which is quite annoying.

Regards,
Juliano



Attachment(s):
ResharperCodeInspectionTest.zip
2 comments
Comment actions Permalink

Hello Juliano,

  I logged a new ticket to YouTrack http://youtrack.jetbrains.com/issue/RSRP-416709 for deeper investigation.

  You are welcome to track its status.

Thanks!

0
Comment actions Permalink

Thank you very much. I'll keep an eye on that issue for sure, and in the meantime I'll deactivate the checks on our build process.

0

Please sign in to leave a comment.