Disable analyze for generated files.

I writing plugin that analyze our own XAML like markup files. That files linked (like in WPF) with generated part (*.g.cs files) and user part (*.cs files). Problem is that generated files including in our project (because of project building problem inside Visual Studio). So, resharper analyze that files as normal *.cs files, search there for fields, methods, etc. But, like in wpf, fields actually declared in our markup files through "x:Name" attribute. For example:
Markup file:
<?xml version="1.0" encoding="utf-8" ?>
<UserControl x:Class="MyUserControl"



 <Panel x:Name="Test">


Generated cs file:
partial class MyUserControl : System.Windows.Markup.IComponentConnector

 private Panel Test;

void System.Windows.Markup.IComponentConnector.Connect(Int32 index, Object target)


 switch (index)


 case 1: Test = (Panel)target; break;



User cs file:
public partial class MyUserControl

public void SomeMethod()


Test.Width = 200;


In my plugin I'm creating new type declaration for type MyUserControl and add field declaration to ITypeDeclaration.MemberDeclarations for x:Name="Test". But this member declaration conflicts with member, that declared in generated file and resharper highlight usages of this field as error with duplicate name tooltip.
The question is: Can I ask resharper to not analyze my generated files from plugin, or from any settings? Or can I manually (from my plugin) remove some type declarations of IDeclaredElement?
I'm already try "Skip Files and Folders" settings and "Generated Code" settings in resharper with no success. If I add generated files to "Skip Files and Folders" - those files not highlighted by resharper, but their content is readed and added to intellisense.


I think you've got two options. The simple one is to just let ReSharper analyse the .g.cs files, and let it add those type declarations to the code model as normal. Don't add the type declarations from your XAML-like files. Instead, add a reference between the x:Name element and the generated type in the .g.cs file. This way, you will still get navigation and find usages, and performing a rename on the x:Name will rename the generating file, and vice versa.

Alternatively, you could try to return custom IPsiSourceFileProperties for the .g.cs files, which returns false for ShouldBuildPsi and ProvidesCodeModel. If I remember this correctly, ShouldBuildPsi is whether the file is parsed, and ProvidesCodeModel is whether the file structure is added to the project. So, if ProvidesCodeModel returns false, the type and type members of that file are not available for navigation, code completion, etc. Normally, files would return the same value for both settings - if it's parsed for a PSI, it provides the code model. An exception to this would be external sources - decompiled files would create a PSI for internal navigation, etc. but not provide anything to the code model, as the decompiled information is already available from the original assembly.

In order to do this, you need to implement IPsiSourceFilePropertiesProvider as a [PsiComponent]. This allows you to return the IPsiSourceFileProperties for a given file. The providers are stored in an ordered list that receives the properties from the previous provider in the list. So, the provider can choose to do nothing by returning the previous properties, or can choose to override them completely by providing a new set or properties, or return a decorated version that delegates back to the original properties. The IPsiSourceFileProperties.Order property defines the value for ordering the files, lowest value being first in the chain. If you look at NuGetPsiSourceFilePropertiesProvider or DoNotBuildForHugeFiles in dotPeek you can see an implementation.


Thank you, Matt, for your extended answer. I'm success with IPsiSourceFilePropertiesProvider!


Please sign in to leave a comment.