Author |
Share Topic Topic Search Topic Options
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
Topic: DF2012 findings 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)]
Edited by smi-mark - 21-Sep-2012 at 8:07pm
|
|
mgood
IdeaBlade
Joined: 18-Nov-2010
Location: Emeryville, CA
Posts: 583
|
Post Options
Quote Reply
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.
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
Posted: 24-Sep-2012 at 7:25am |
A logging element is added to the web.config regardless of whether one exists already.
|
|
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
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.
|
|
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
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?
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
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.
|
|
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
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.
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
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
|
|
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
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.)
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009
Location: Dallas, Texas
Posts: 343
|
Post Options
Quote Reply
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.
|
|
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
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.
|
|