Is it possible to exclude a complete namespace from all FxCop analysis while still analyzing the rest of the assembly using the SuppressMessageAttribute?
In my current case, I have a bunch of classes generated by LINQ to SQL which cause a lot of FxCop issues, and obviously, I will not modify all of those to match FxCop standards, as a lot of those modifications would be gone if I re-generated the classes.
I know that FxCop has a project option to suppress analysis on generated code, but it does not seem to recognize the entity and context classes created by LINQ 2 SQL as generated code.
If you tag your classes with the [GeneratedCode] attribute, you can use the /ignoregeneratedcode flag with FxCop as described in this MSDN post:
FAQ: How do I prevent FxCop from firing warnings against generated code
You may have to add a new code file and implement new partial classes there to add the attribute to the classes:
[GeneratedCode]
public partial class MainDataContext { }
Just make sure you add everything to the correct namespace when you create your new file.
Add a [GeneratedCode] attribute to the classes.
EDIT: I meant to partial classes with the same names, as explained by the other answer.
Use the Generated Code Attribute, heres the blog post from the Code Analysis team on the subject.
This at the top of the namespace should do the trick:
[GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "9.0.0.0")]
<Assembly: SuppressMessage("Microsoft.Design", _
"CA1020:AvoidNamespacesWithFewTypes", _
Scope:="namespace", _
Target:="Missico.IO")>
Put statement in GlobalSuppressions.vb at root of project.
All I have is VB example.
Related
It took me a while to even understand the problem I'm about to describe, so please let me know if the description is confusing...
I have an object called "cProp" that defines a number of sub-classes. To refer to these classes in other files in the project, I have to do something like...
Dim cp = New cProp.InflationRow()
I understand why this is; since the InflationRow is "inside" the cProp, I need to tell it where to find it. Fine.
But this, of course, gets tedious, so sometimes you want to fix it...
Imports cProp
Why doesn't that work? Why do I have to...
Imports ProjectName.cProp
You might wonder why I care, but these files are used in numerous projects with different names. So if I use Imports I have to change the project name in a bunch of places. I am aware that Namespace is likely the solution I want, right?
My confusion stems from the fact that the compiler can figure out just fine which cProp (which is the only one) I'm referring to in the code, so why not in the Imports? I think I'm missing something fundamental here.
It's because your project has a root namespace - you can see this in your project properties. You can delete this in the project properties - this will result in allowing you to simply use the class name from another project. However, namespaces are a good way to organize your classes. In VB, the project defaults to having a root namespace, which you don't see in your code files.
Within your project, since it seems to be all within the same root namespace, you don't have to qualify with the root namespace for code within the root namespace. The "Imports" statements are not within a namespace (only types can be within namespaces) - that's why you have to provide the full qualification there.
I am trying to add a property to our custom build configuration for a C++ project. I want the property combo box to display a dynamic list of values that I can set in code. I think that this should be done using the DynamicEnumProperty type but I am unsure of its implementation. Has anyone worked with this property before that can point me in the right direction?
Thanks
I know it's a bit old question... but you might still enjoy the solution ;)
Beside referencing the assemblies and exporting desired type via MEF as Dmitry explained above, you also need to mark the VSPackage as MEF-enabled to make it scan though your contracts. Do it by editing source.extension.vsixmanifest:
for VS2010:
<Content>
<VsPackage>|%CurrentProject%;PkgdefProjectOutputGroup|</VsPackage>
<MefComponent>|%CurrentProject%|</MefComponent>
</Content>
for VS2012 / VS2013:
<Assets>
<Asset Type="Microsoft.VisualStudio.MefComponent" d:Source="Project"
d:ProjectName="%CurrentProject%" Path="|%CurrentProject%|" />
</Assets>
This should let you hit a breakpoint set in an exported class.
Additionally, if you need to create an object at runtime 'manually', you can use VisualStudio's internal composition container. The simplest way to access it from anywhere is:
var container = Microsoft.VisualStudio.Shell.Package.GetGlobalService(typeof(SComponentModel)) as IComponentModel;
var service = container.GetService<SVsXYZ>();
I will shortly add a sample here: https://github.com/phofman/vs-plugin, so just putting the link for future reference.
In your VSPackage (or any MEF-exposed DLL referenced by it) create a class implementing IDynamicEnumValuesProvider and add [Export(typeof(IDynamicEnumValuesProvider)), DynamicEnumCategory("MyCategory")] to that class's attributes. Then add EnumProvider="MyCategory" to the DynamicEnumProperty definition and your class will be used as the values provider.
Make sure your package references Microsoft.VisualStudio.ProjectSystem.Utilities.v12.0.dll and Microsoft.VisualStudio.ProjectSystem.V12Only.dll (for VS2013) or similar assemblies for earlier versions.
MVC 4 Beta project fails to compile after upgrading to .Net 4.5.
This happens due to conflict between
System.ComponentModel.DataAnnotations.CompareAttribute and System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties.
While System.Web.Mvc.CompareAttribute MSDN documentation says:
Provides an attribute that compares two properties of a model.
What is the difference between the two and when it would be "smarter" to use each of them?
10x.
So, looking at the MSDN documentation and doing a literal comparison of the two classes, I noticed both classes are derived from System.ComponentModel.DataAnnotations.ValidationAttribute. In fact, the classes are almost exactly the same. The only notable difference is that the MVC version also implements IClientValidatable which adds the following properties:
FormatPropertyForClientValidation - (static member) Formats the property for client validation by prepending an asterisk and a dot.
GetClientValidationRules - Gets a list of compare-value client validation rules for the property using the specified model metadata and controller context.
As for which class you should use, if the model will be directly bound to a view, use the MVC version so that you can take advantage of the client-side validation. However, if you're using ViewModels, you can stick with the ComponentModel class and avoid the unnecessary overhead of the additional properties. Your call!
System.Web.Mvc.CompareAttribute
System.ComponentModel.DataAnnotations.CompareAttribute
Microsoft Connect work-around is:
Posted by GavK on 6/17/2012 at 5:13 AM
I added a full reference to [System.Web.Mvc.Compare(...)] rather than
just using [Compare(...)]
Works for me in VS 2012...
Vinney nailed most of it with the exception of which one you should use...
The reason you have a conflict after changing your target framework to 4.5 is because prior to .NET 4.5 there was no CompareAttribute class in the System.ComponentModel.DataAnnotations namespace and the class defined under System.Web.Mvc filled the gap. Therefore, as an example if you were using [Compare] and [Required] attributes in your model class prior to updating your target framework you ended up with a conflict when you upgraded.
Assuming you are not using anything else in the System.Web.Mvc namespace in your model class, you should remove that using statement and let it rely on the System.ComponentModel.DataAnnotations namespace. Unobtrusive client-side validation will continue to work exactly as it did before, just as it does for other attributes that you decorate your model's properties with from the same namespace (eg Required).
If you wish to be explicit about the reference, you can simply add this line:
using CompareAttribute = System.Web.Mvc.CompareAttribute;
Using Visual Studio 2013 (MVC 5 project, .NET 4.5) the IntelliSense suggests that System.Web.Mvc.CompareAttribute is deprecated.
I used System.ComponentModel.DataAnnotations.CompareAttribute and it works fine.
It also does the client-side validation!
On this post, they also suggest another solution, which is to move the reference of the preferred namespace for Compare() inside the model's namespace. Eg. if you prefer to use Compare from System.Web.Mvc, use:
using System.ComponentModel.DataAnnotations;
namespace MyProject.MyViewModel
{
using System.Web.Mvc;
The compiler will search inside the model's namespace first.
I have a project written in MVC2 and VB.NET. I use a lot of htmlhelper extension methods, and I have them all in a public module. They work just fine, and I can compile and run my project. I reference the namespace they are in with this:
<%# Import Namespace="MyProject.WebUI.Extensions" %>
So, again, they work great, my project runs and compiles without a hitch.
The problem is that each one of these extension methods is shown as an error:
Error 33 'TabbedMenu' is not a member of 'System.Web.Mvc.HtmlHelper(Of Object)'. C:\Projects\MyProject\MyProject.WebUI\Views\Shared\Site.Master 23 21 MyProject.WebUI
This doesn't prevent the project from compiling and running, it just creates an error, which is annoying. I've tried looking for solutions, but all of the solutions I've found were for projects that don't compile, all with simple solutions like referencing the right namespace or making sure your module is declared public. Any thoughts?
Have you included an import statement in your site.Master to include the extensions class where your extensions are defined. Also I assume your extension class is a public static class with public static methods defined?
Also check this out if you haven't already, it may be related to what you are after.
How do I use an extension method in an ASP.NET MVC View?
You need to import the namespace where you have placed your extension. And since it is a bit annoying that this problem shows up no sooner than in runtime, you can enable view compilation to have the compiler detect the problem. I should warn you that compiling the views is a time consuming operation though.
I have a class (e.g. MksMath) written in IronPython using SharpDevelop 3.2. After compiling it for class library, it produced the following output:
IronPython.dll
IronPython.Modules.dll
Microsoft.Dynamic.dll
Microsoft.Scripting.Core.dll
Microsoft.Scripting.Debugging.dll
Microsoft.Scripting.dll
Microsoft.Scripting.ExtensionAttribute.dll
mksmath.dll
If I try to add reference to all above dll and import "MksMath", I am unable to access it. The vbc is throwing the following error:
Namespace or type specified in the Imports 'MksMath' doesn't contain any public member or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
I am new to IronPython. Kindly advise how to use this class in my vb.net code?
I post here my answer that I posted to IronPythopn mailing list :-)
You cannot use mksmath.dll directly from VB (see Compiling Python code into an assembly) so you have to host IronPython engine in your VB app and use mksmath.dll from the engine. See Using Compiled Python Classes from .NET/CSharp IP 2.6 for example (in C#).
Here is a link that I think may solve the issue. http://msmvps.com/blogs/theproblemsolver/archive/2008/08/14/calling-ironpython-functions-from-net.aspx