Resharper CLI (InspectCode) fails for non default Configuration|Platform

I'm not exactly sure how you guys are opening the solution file, but there seems to be a bug there somewhere.

This solution of ours, "Mobiltec.Framework.Net40.sln", contains various projects with the default Debug|AnyCPU configuration as usual, but there is one project there that uses a specific platform because of a dependency with a non MSIL assembly from Oracle (

Due to this dependency, my extension project also needs to be set to x86 (which makes a lot of sense and is ok), and this is the result of running the inspectcode.exe tool on the solution:

INFO: Opening solution D:\TFS05\Framework2\Main\Sources\Mobiltec.Framework.Net40.sln
INFO: Default location will be used to store solution caches.
ERROR: The OutputPath property is not set for project 'Mobiltec.Framework.Oracle.csproj'.  Please check to make sure that uou have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='AnyCPU'.  You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. in file 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets' at (609:5)

The question then is: why are you using this specific configuration to open the solution? Visual Studio works fine with it because if knows that the .Oracle project's default platform is not AnyCPU, but x86.

I want to run the tool on the TFS build process but if there is a project with a different configuration|platform in the solution I get various errors that are not supposed to be there.

Is there any setting for the tool that makes it use the default combination for each project, like VS does?

Comment actions Permalink

Hi Juliano.

Can you compile your solution from comman line with msbuild?


Comment actions Permalink

Hey there again Slava.

I don't usually compile from the commandline, but the build process itself does, and it works fine. Let's see this now...

Yes, compiling via commandline works flawlessly here, no parameters passed etc:
msbuild <path_to_solution>

One of the very first logged lines is this:
  Building solution configuration "Debug|Mixed Platforms"

Msbuild is correctly using the solution default configuration for building it, while your tool is using "Debug|AnyCPU" on this same solution, for some reason.

It's been a busy week with integrating the inspectcode.exe into the build process. I'm having another problem just now in that when I run the tool on the build server agains my solution, I get a very high number of 'Cannot resolve symbol X' messages, while running the tool locally does not show them. I wonder if I should create yet another thread for this or talk to you about it here.

Is there a documentation for how exactly the code inspection tool works? One thing which is indeed different when on the TFS build process is the output directory for the generated assemblies. I guess this is messing things up because the tool is trying to search on the default folders while msbuild sent the binaries to somewhere else by overriding the outdir property for the solution. Do you guys actually look into the out dir in the algorithm? Perhaps this is only the case when trying to find project references (projects that reference other projects in the same solution).

I'm having problems here with two test projects, and they have project references to the two actual projects. Sorry for going on a bit of a tangent here. If needed, I'll create another topic about that.


Comment actions Permalink

We don't do any special processing of output folder or parameteres - we just use MsBuild.
But, some properties, like $SolutionDir$ are available only in VisualStudio, you need to provide them by himself, if you use them.
You can do it by /properties command line parameters (
But, again, you need to provide them for your CI server too, but if you don't - then you will not need them for CLI too.
And what do you mean by generated assemblies?
CLI does not compile project, so it should not be any generated assemblies.
If you can post you solution and project files, without other sources, I can look on configuration selecting.
Better to do it in tracker,

Comment actions Permalink

Unfortunately I can't share the solution "as is" with you since it is proprietary code, but I'll try to reproduce the problem with a small sample solution and post the bug on the tracker. I think it is very simple to reproduce, so I should be able to post it by Monday when I'm at work. About the tracker link, I got this message  on the top of the page:
"unknown command: Assignee derigel"

And back to the other discussion, "we just use MsBuild." I did not know this, I think it partially explains the problems I'm having. The new build template files (Workflow Foundation xaml) on TFS 2013 are much more simple than the ones I had experience with. Previously, it was detailed to the point of invoking msbuild for each individual project file passing parameters, explicitly on the workflow, but the new ones include a generic batch "MSBuild" activity that only get's the list of projects to compile, so it will be harder to customize it and tap the same parameters to pass them to the InspectCode CLI, I would really like to avoid that if possible.

As for my "generated assemblies" comment, I meant the compiled dll files that are created on the output folder for each project. Normally, this folder is configured per project, for example [projectDir]\bin\[configuration]. What I thought was happening was that locally, the CLI was basing itself on this property to find the referenced assemblies for each project. If this really is how it is implemented I'll have some issues to use the CLI on the build server. Perhaps it's useful to describe how exactly our build process works here so that you can more specifically help me:

For this particular project, we have 4 solution files, each one of them for a specific platform, like the following:

  • [project].Net35cf.sln
  • [project].Net40.sln
  • [project].Net45.sln
  • [project].Silverlight5.sln

The build process is configured to build all of them. Without custom configuration, the default TFS build template already builds the projects a little differently than what is done locally. It outputs every built assembly to the same output folder, instead of respecting each project's configured output folder. It does this by overriding the output folder for the projects by passing the property to msbuild CLI during compilation.

For this particular project, we use yet another "output mode" though, in which it outputs the binaries for each solution to a different folder, which gives us 4 directories in the drop folder for the build, each containing all assemblies generated by it's corresponding solution.

This explanation was long, but I figure it should be useful as context to my questions and contribute to any advice you can give me later on.

Ideally, the CLI woudn't need to find the dll files of referenced projects, since it has access to the code of all of them. I can see that when the references are file references, this is impossible, and the tool would have to check the actual dll files. This is what happens with nuget references for instance, and is ok in my case since the packages are in a known location (the build process does not change their paths). The problems I'm having with the 2 test projects I mentioned eariler does seem to imply the tool is trying to find the compiled dll files of project references too though, which I would guess is unnecessary.

Can you comment on how the tool uses referenced projects information? Does it really try to read the compiled dlls of these projects? If yes, would it be feasible to change this behavior and make the tool use the code files of these projects instead of their dlls? If no, why am I getting these errors when running the CLI on the build but not when I run it locally.

Sorry for the long reply, I tried to be as descriptive as possible with this one.
Thanks again Slava for the support here.



It appears this bug has already been opened and apparently solved? While typing my issue I found a complaint very similar to mine:

I can report that this still happens, but I've found exactly what is causing it now in my case: the csproj is declaring that it's default platform is "Any CPU" but later on in the same file there is no PropertyGroup which uses this configuration. For some reason, Visual Studio does not change this default platform when you remove a platform from a project through the configuration dialog. Still, msbuild is able to assume that the project platform is x86 and not Any CPU, while your tool cannot.

I've managed to reproduce it very cleanly with a simple solution, but now that the issue is duplicated I'm not sure how to share it with you. I'll just attach to this message and wait for your suggestion.

Message was edited by: Juliano Goncalves


Ok, in regards to the error messages I mentioned earlier, it has to do with the version of msbuild that the tool is using. We are using MSBuild 12 on the build server (this is the new versioning they are going for, same version as Visual Studio) while the tool is using MSBuild 4. This results in all kinds of issues, since v4 looks for .targets files on different (older) folders. By running the tool inside the build server I could see the log messages pointing that they could not find the Web.Targets file so that's why the test projects where filled with errors, because the reference to the original web project was just broken.

Unfortunately, I'm still having problems with Compact Framework and Silverlight 5 projects... for those, there is no error message when loading the solution, but I get numerous errors like:
"Cannot resolve symbol 'string'"
"Cannot resolve symbol 'object'"

This is weird, it seems to be using the default .Net System dll instead of the one for smart projects and silverlight. What can I do here?

Message was edited by: Juliano Goncalves


Please sign in to leave a comment.