Print Page | Close Window

DF2012 findings

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2012
Forum Discription: For .NET 4.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3644
Printed Date: 13-Mar-2025 at 10:35am


Topic: DF2012 findings
Posted By: smi-mark
Subject: DF2012 findings
Date Posted: 21-Sep-2012 at 2:59pm
I'll use this post to note some of my findings from upgrading and using DF2012.

1) I have found that there are issues if you have the DF2010 and 2012 designer extensions enabled.

2) Issue in the model generation. I have a verifier that looks like:

[MyModel.SettingValueIsTypeVerifier(DisplayName = "SettingValueIsTypeVerifier", ExecutionModes = VerifierExecutionModes.InstanceAndOnBeforeSetTriggers)]

I get a namespace issue on VerifierExecutionModes. The correct line should be:

    [MyModel.SettingValueIsTypeVerifier(DisplayName = "SettingValueIsTypeVerifier", ExecutionModes = IbVal.VerifierExecutionModes.InstanceAndOnBeforeSetTriggers)]


Replies:
Posted By: mgood
Date Posted: 22-Sep-2012 at 4:17am
Mark,
Thanks for the feedback. To point 1) it is mentioned in the release notes that side-by-side installation of DF 2010 and DF 2012 is not recommended. Depending on what you do it works, but it can cause issues. 

Posted By: smi-mark
Date Posted: 24-Sep-2012 at 7:25am
A logging element is added to the web.config regardless of whether one exists already.

Posted By: kimj
Date Posted: 24-Sep-2012 at 12:21pm
As Marcel mentioned, we don't recommend a side-by-side installation of DF2010 and DF2012.  If you have DF2010 installed, you should disable the "DevForce EDM Designer Extension for VS2012" from the Tools | Extensions and Updates menu.  This is the extension for DF2010, and will pop up quite a few error messages when enabled and you open the EDMX in a .NET 4.5 project.
 
The duplication of the logging element is due to a problem with the web.config transform.  We hope to have this fixed in the RTW release.  You can safely remove any duplicated element, as everything added is for a "standard" new EntityServer and not a new required setting.

Posted By: kimj
Date Posted: 24-Sep-2012 at 12:24pm
In the model generation issue, are you using a "buddy" class to add the verifier, or do you have a custom T4 template?

Posted By: smi-mark
Date Posted: 26-Sep-2012 at 5:49pm
Kim: We use a buddy class that does this:

    public class VerifierProvider : IVerifierProvider
    {
        public IEnumerable<Verifier> GetVerifiers(object verifierProviderContext)
        {
            return new[] { SettingValueIsTypeVerifier.CheckSettingValueIsTypeVerifier(typeof(Setting), Setting.PropertyMetadata.Value.Name) };
        }
    }

It then writes out the full namespace rather than IbVal.

Posted By: kimj
Date Posted: 27-Sep-2012 at 2:56pm
Mark, thanks for the update.
 
The code generation for attributes specified via a MetadataType "buddy" class is working the same as it does in DF2010.  We don't translate or parse any part of the attribute arguments.  For example, the RequiredValueVerifier attribute below will be generated "as is" into the final code file.
 
[MetadataType(typeof(EmployeeMetadata))]
public partial class Employee  {}
 
public class EmployeeMetadata {
  [RequiredValueVerifier(DisplayName = "The City", ExecutionModes = VerifierExecutionModes.All)]
  public static string City;
}
 
As you noted this can result in unresolved types, but knowing that the arguments are copied as is, you can change the attribute args to whatever you need, for example:
 
[RequiredValueVerifier(DisplayName = "The City", ExecutionModes = IbVal.VerifierExecutionModes.All)]
 
I'm confused about one thing, though.  The verifier attributes found through the IVerifierProvider are done so at run time, while the metadata buddy class attributes are applied during code gen.  While there can be good reasons to define some verifiers through code gen and some at run time, there's probably no need to generate the same verifier onto a property as an attribute and also apply it via a verifier discovered at run time.
 

Posted By: smi-mark
Date Posted: 27-Sep-2012 at 5:35pm
Hi Kim,

I'm not sure the reasoning for that. But yes I have noticed in our metadata class it does exactly as you say. I will change that and I expect it will work.

Thanks,

Mark

Posted By: kimj
Date Posted: 27-Sep-2012 at 5:59pm
Not sure about why we're not doing anything with the attribute args?  I haven't spoken with the original developer, but I do know that we're using the VS code model to grab these attributes, and the model is not easy to work with.  You must navigate through CodeElements to find the CodeAttribute describing the attribute, and the CodeAttribute does not provide much information without drilling into further, so I'd guess it was decided that copying the arguments as is would be faster and meet "almost" every use case. 
 
We have considered dropping support for the metadata buddy class altogether in DF2012, since it's been somewhat buggy and not heavily used.  How big an impact would this be for you?  (If we do decide to remove it, we'll likely deprecate it for 3-6 months, and not spring the surprise in the RTM.)

Posted By: smi-mark
Date Posted: 27-Sep-2012 at 6:34pm
Sorry, I should have been more clear. I'm not sure why we are using two validation methods. I think we probably switched at one point and forgot to remove some old code.

What is the preferred way now? Using the IVerifierProvider?

I don't think it would be a big impact for us. Even if we do use buddy classes it's not difficult to switch.

Posted By: kimj
Date Posted: 27-Sep-2012 at 7:13pm
DevForce itself doesn't have a preferred way to add verifiers, since at run time once the verifiers are found whether they came from attributes or were dynamically loaded doesn't matter.  
 
The IVerifierProvider is good for injecting verifiers at run time, and gives you more flexibility in what you can do.
 
When verifier attributes are wanted the alternatives to the buddy class would be customizing the T4 script (which is not always painless) or using Code First.  We haven't made any decisions on the buddy classes, it was just something that came up in terms of cleaning up problematic parts of the API. 


Print Page | Close Window