FxCop Suppression - asp.net

I have a control on an Asp.Net page, on that page is a control with the name "PaReq" that violates the rule:
CA1704:IdentifiersShouldBeSpelledCorrectly
I've used suppression before I'm not sure how to suppress this error since it is defined in the generated file.
I could do this in a custom dictionary but that would mean all the developers would need to keep sync a copy of this dictionary which is something I'd rather avoid if possible. Also that the term "PaReq" is only used in this project.
How and where would I apply the suppression?

I keep a custom dictionary per project which contains specific words for that project.
That dictionary file is in my SourceControl repository, so other developers can use it (and add new words) as well.

AFAIK you can add a suppression at the Assembly level although I've not used it in anger! You'd end up with some false negatives if you do that. (i.e. suppress all of the incidents that break this rule).
[SuppressMessage("Microsoft.Design", "CA1704",Scope="Assembly")]
I think the custom dictionary in source control is the best option, alternatively you could keep the FxCop project in source control.

Related

Executing a method which is named via a config file

In short: I have a method name provided via a JSON configuration file. I'd like to call a method using this provided name. The method (with a matching name) will exist in the backend. What's the best way of going about this?
I am not quite sure what I should be searching for as an example.
To detail: I am working with a legacy application, hence the VB.NET. I am building a single PDF file from multiple PDF sources. Most of these are as is, I simply read the configuration and grab the relevant files and the job is done. However some require processing, I'd like the configuration file to pass in a method name to be called that will perform extra processing on the PDF, whatever that may be.
As there can be a lot of PDF files that can vary, I cannot simply use a property such as "PostProcessing: true".
Any ideas?
You could use reflection to reflect method names back and check them against the name passed from the property in the config file.
Like so
Type magicType = Type.GetType("MagicClass");
MethodInfo magicMethod = magicType.GetMethod("ItsMagic");
object magicValue = magicMethod.Invoke(magicClassObject, new object[]{100});
That would work.. but to be honest, I'd go with a case statement as you'll be hardcoding the method names anyway (because they are code), and it'll be strongly typed (less chance of typos and errors).

JSR 303 and property file

If I'm using JavaBean Validation 1.0 (JSR 303), and I extract my validation messages into a property file how does Spring become aware of my property file? I know I need to declare a ResourceBundleMessageSource bean but I'm just not clear on how Spring/JavaBean validation becomes aware of this file?
That is main idea of "Framework". It makes lots of magic/setups behind of scenes, so you don't have to write thousands rows of boilerplate code for every project. You can follow with default path/settings (messages.properties) or switch to something else using Configuraton or application.properties file (which also can be changed). But for sure, you don't want to do that in most cases, but you can.

Can name from build.sbt depend on Activator name in activator.properties (or vice versa)?

Just noticed that there are two name settings in any Typesafe Activator template - one in build.sbt and another in activator.properties.
Is there a way to make one depend on (use the value of) the other? Although the build's name can be defaulted to the name of the main project folder, I'm not sure about the activator's.
You could make build.sbt write out or modify activator.properties, using whatever scala code you want to use for that.
But you'd still have to check activator.properties in to git because the Activator template-publication system does not run sbt on the project, it just looks at the files in git.
And also your nice template intended for end-users would end up with some extraneous build code in it to generate activator.properties, which would clutter up the example.
You could try going the other way but I think it won't work.
In sbt, name is a setting rather than a task, and is thus evaluated only once -- so if you made it read from activator.properties, you'd need to restart (or at least reload) your sbt build whenever you edited activator.properties. But you could read from activator.properties using whatever scala code you like. Something like:
name := {
val props = new java.util.Properties()
props.load(new java.io.FileReader(file("activator.properties")))
props.getProperty("name")
}
However, this is going to fail for two reasons.
When a template is instantiated (cloned) by an end user:
activator.properties is dropped
activator tries to replace the name in build.sbt with a user-selected one
So on clone, first the above code would fail due to missing activator.properties, and second the user's selected name wouldn't be swapped in (because the above expression is too complicated for activator to figure out how to replace it).
This name-replacement means your build.sbt name will get dropped in most cases anyway. The one exception is if the user downloads the "template bundle" (a pre-cloned zip of the project) from the template's detail page on typesafe.com, then the name in your build.sbt would be kept.
Note that if you ever change the name in activator.properties then you'd end up duplicating your template (you'd effectively be publishing a new template), so you may not want to abstract this anyway -- you should change it only when creating a new template is your intent.
Perhaps the bottom line is KISS -- write the name in two places. The alternatives are all going to cause headaches.
The only way I can think of to make this sane would be to have some code outside of the template which generated the template. Akka and Play both do this, I think, for templates that are part of the larger akka and play source trees. But at this point you're definitely doing more work than I'd do just to avoid copying one name string around, you'd want to have some other reason to go there.

.Net Inline Schema/XML Programmatic Generation for Excel

I have a set of data rendered using ASP.Net (VB.Net) to a web page. I now want to export that data to XML. I have created some code to generate a schema, however, I don't know what to do next. I want to have the schema be in-line with the XML data, and I would like the compiler to check to make sure that the data I'm entering for the XML content validates against the included schema. Anyone know of a way to do this? The idea is for me to be able to open the resultant file in Excel with fields of the correct type.
I've build XML documents before, and this is my first schema document I've created programmatically. However, I've never worked with inline schema's, much less used them to strongly-type the XML being added to the document.
I've read over the following, which were quite helpful, but neither of which addressed the issue I mention above:
http://www.aspfree.com/c/a/XML/Generating-XML-Schema-Dynamically-Using-VBNET-2005-Essentials/
http://blogs.msdn.com/b/kaevans/archive/2007/06/05/inline-an-xml-schema-into-your-xml-document.aspx
I have no idea what you mean by "... I would like the compiler to check to make sure that the data I'm entering for the XML content validates against the included schema."
The compiler never checks that. If you want to validate your XML Document against a schema programmatically, you should probably use http://msdn.microsoft.com/en-us/library/system.xml.schema.xmlschemavalidator.aspx.
But for inlining the schema with your document, you sort of answered your own question. The second link in your question, to http://blogs.msdn.com/b/kaevans/archive/2007/06/05/inline-an-xml-schema-into-your-xml-document.aspx, is exactly what you are trying to do.
You can think of an inline XML Schema as a document-within-a-document. Well, using Kirk's example, the outermost document is more of a container which uses the undefined namespace (no schema). His example uses a document root of "DerekDoc" that belongs to the undefined namespace. You can name yours whatever you want.
Inside that root are essentially two documents. One is the inline XML Schema. You would just add it as a child element of the root. The other is the XML document that you intended to conform to the XML Schema. You will need to use the xmlns attribute to set this element to the namespace defined by your XML Schema (the target namespace of the schema).
It might work (I haven't tried it) to set the root element to the target namespace of the schema, but it might be harder for clients to validate the document since it's a forward reference.

Creating blank dummy Components which contain mandatory Fields with the SDL Tridion 2011 Core Service

I wanted to create a blank Component in SDL Tridion 2011 using the Core Service. The only information I have at the start of the process is the Schema URI. The Schema may contain any kind of field (text, rtf, number date, embedded etc), some of which may be mandatory.
I understand that for the mandatory fields, I will need to save some dummy value in them, and this is acceptable as they will be changed manually later.
How can i achieve this?
First - you make sure all fields are set to optional in the schema, otherwise this will never work.
Second - You save.
When an optional field has no value, it will have no XML representation. If you have a schema that defines a component like this:
Field1
Field2
Field3
When all fields are optional and you save a value in Field 2, Tridion will store the following:
<Content xmlns="yourNamespace"><Field2>SomeValue</Field2></Content>
If one of your fields is not mandatory, then you'll have to provide a value. If you're using the CoreService then you can use ReadSchemaFields class to get the fields and some information about them - what type, mandatory/optional, etc.
Looking at your question/requirement to understand what you're exactly looking for, so we can answer the best possible and relevant.
Are you asking for "How can you write a generic code for component creation using core service?" instead of creating a component with a specific schema knowing all the fields upfront.
If that is what you are looking for, here is what you need to do:
You need to read the schema fields with CoreService (since you know the schema URI)
Now you know what type of fields (embedded/component link etc) you need to create content for
use the links pointed by "Puf" in his answer.
Please note that, if the field is marked as required in Tridion Schema you must have to fill a value and it has to match the field type defined in schema.
Reading schema fields via Core Service sample code can be found here
Updating a Component's field through the Core Service is already answered here: Updating Components using the Core Service in SDL Tridion 2011
That post points to a helper class you can find here: Updating Components using the Core Service in SDL Tridion 2011
If those don't help you in creating a Component, I suggest you post your code instead of asking us to write it for you.
We ask about use case, because code to fill in specific fields for a specific schema only works in one environment. Code that can automatically determine fields is re-usable.
If the use case is for an Tridion setup that has Inline Editing (Experience Manager or SiteEdit), then the correct approach is content/component types. These define a reference component with "junk defaults," instructions to the author, and even save location context.
If the use case is to allow authors the ability to create dummy components, this is out-of-the box with:
CTRL+C
CTRL+V
One-time setup required to create a "reference component." Of course we can mimic this behavior (in case "Copy of Untitled" isn't an appropriate name) by copying items with the core service.
In that case, I'll also do a copy--see a general solution for creating Tridion items using the Core Service.
Fields that require a default can have an actual default in the schema.
"Junk values" don't help authors much, always consider good defaults such as an appropriate selection or instructions in the case of fields (maybe). A 10 second change costs development practically nothing, but impacts all future components and the authors that create them.

Resources