I have looked at the examples for using DI for validation.

But when I test it, nothing happens.

If I use the protected override bool OnValidateFieldValue(int fieldIndex, object value) method in a partial class for the entity I am using to validate it, it works.

I have created a Validator class library project with a single class in it called Validate.data.Validators.

namespace Validate.Data.Validators
{
    [DependencyInjectionInfo(typeof(PriorityEntity), "Validator")]
    [Serializable]
    public class PriorityValidator : ValidatorBase
    {
        public override bool ValidateFieldValue(IEntityCore involvedEntity, int fieldIndex, object value)
        {
            // value to return
            bool fieldIsValid = true;
            Debug.WriteLine("PriorityValidator ValidateFieldValue");
            if (value != null)
            {
                switch ((PriorityFieldIndex)fieldIndex)
                {
                    case PriorityFieldIndex.PoliceCaseType:


                        if (((int)value) > 3)
                        {
                            fieldIsValid = false;
                            involvedEntity.SetEntityFieldError(PriorityFieldIndex.PoliceCaseType.ToString(),
                                                               "Priority must be < 4", false);
                        }
                        break;
                }

            }
            return fieldIsValid;
        }
    }
}

I build the class library and reference it in my main startup project. Not sure if I should reference it but I do anyway.

In the app.config I specify

<?xml version="1.0"?>
<configuration>
  <configSections>
    <!-- ENABLING DEPENDENCY INJECTION
        For more info read "LLBLGenPro Help - Depedency Injection mechanism"-->
    <section name="dependencyInjectionInformation" type="SD.LLBLGen.Pro.ORMSupportClasses.DependencyInjectionSectionHandler, SD.LLBLGen.Pro.ORMSupportClasses.NET20, Version=2.6.0.0, Culture=neutral, PublicKeyToken=ca73b74ba4e3ff27"/>
  </configSections>

  <!-- SPECIFYING DI INFORMATION
    Comment/Uncomment assemblies to enabled/disabled Auditors injected to your EntityClasses
    For more info read "LLBLGenPro Help - Depedency Injection mechanism" -->
  <dependencyInjectionInformation>
    <additionalAssemblies>
      <assembly filename="Validate.data.Validators.dll"/>
    </additionalAssemblies>
  </dependencyInjectionInformation>
    <appSettings>
        <add key="Main.ConnectionString" value="data source=pcp19006\wardendev;initial catalog=WardenII;integrated security=SSPI;persist security info=False;packet size=4096"/>
    <!--<add key="buildInValidationBypassMode" value="0"/>-->
    <add key="autoDependencyInjectionDiscovery" value="true"/>
    </appSettings>

  <system.diagnostics>
    <switches>
      <add name="SqlServerDQE" value="4" />
      <add name="ORMGeneral" value="4" />
      <add name="ORMStateManagement" value="4" />
      <add name="ORMPersistenceExecution" value="4" />
    </switches>
  </system.diagnostics>
</configuration>

Nothing happens. No validation.

How can you debug this sort of thing? How do you tell if ones validator has been injected? can you put breakpoints in your validation class?

If I need to access resources in other assemblies (I want to be able to validate using a spell checker) how does one gain access to these. I mean when the validator is contructed I need to set some references to other objects. Or set a reference in other objects to the instantiated validator class.

Does that make sense?

Additional information

Version : 2.6 Final

SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll Product Version: 2.6.08.0911 File Version: 2.6.8.911

Using the Adaptor template SQL Server 2008 Developer

Is this related to your previous thread about validation which was solved? ( http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=16804 ) If so, is this thread still relevant?

Thanks but its a different issue.

I got that working and thought, that the basics done, now advance onto more interesting stuff. So I had a look at DI for validation. It would not work despite some very colourful language being used.

My problem is that the assembly containing my validation class was not being copied into the correct location (bin/debug) of my main project despite it being referenced.

I simply copied it in and it started working.

I couldn't get anywhere with the debugger, but as there was no assembly present it could not work (it can't perform miracles, at least not everyday).

It would have been nice to debug the injecting of the dependancies to see what is and is not being injected. I am not sure how one does this.

Is there a way one can trace this?

I need to reference other objects (well one anyway) from the validator to handle some validation. I am using a spelling checker and I do not want to instantiate this inside the validator class. It already exists inside another object and it has quite a large dictionary file already opened for it to use. I don't want to duplicate all of this.

I will give it some thought overnight. Probably use some sort of singleton helper class.

Thanks for the prompt reply.

SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll Product Version: 2.6.08.0911 File Version: 2.6.8.911

First thing to do is to use the latest runtime libraries, as you are using a very old one.

I build the class library and reference it in my main startup project. Not sure if I should reference it but I do anyway

No, you don't have to reference the assembly anywhere.

<dependencyInjectionInformation> <additionalAssemblies> <assembly filename="Validate.data.Validators.dll"/> </additionalAssemblies> </dependencyInjectionInformation> <appSettings> <add key="Main.ConnectionString" value="data source=pcp19006\wardendev;initial catalog=WardenII;integrated security=SSPI;persist security info=False;packet size=4096"/> <!--<add key="buildInValidationBypassMode" value="0"/>--> <add key="autoDependencyInjectionDiscovery" value="true"/> </appSettings>

You are mixing between automatic discovery of the DI assemblies and the manual discovery. If this is a win app, then let's try the automatic discovery.

Make sure you copy the validator assembly into the bin (bin/debug or bin/release) folder of your application.

To debug the validator class, add the project to your solution, and place brake points in its validation methods, and see if they ever get hit by your application.

First thing to do is to use the latest runtime libraries, as you are using a very old one.

Ok. But it was working.

No, you don't have to reference the assembly anywhere.

Thats good as in CAB we are writing modules which plug into a shell. I don't want the shells app.config file to get bloated.

Make sure you copy the validator assembly into the bin (bin/debug or bin/release) folder of your application.

That was my mistake. By referencing it I thought it would copy it the validator.dll into the same folder as my shell executable

To debug the validator class, add the project to your solution, and place brake points in its validation methods, and see if they ever get hit by your application.

Yep, debug works well.

Now I only have one major thing to do which is not llblgen pro based and I can proceed forward.

Thanks for all your help.

Actually one last thing

It would have been nice to debug the injecting of the dependancies to see what is and is not being injected. I am not sure how one does this.

Is there a way one can trace this?

The problem with this is that when it does not work, one is not always quite sure where the problem is.

It would be nice to be able to have a debug trace option to view what dependancies are being injected. With that I would have seen that nothing I had done was being injected.

he00273 wrote:

Actually one last thing

It would have been nice to debug the injecting of the dependancies to see what is and is not being injected. I am not sure how one does this.

Is there a way one can trace this?

The problem with this is that when it does not work, one is not always quite sure where the problem is.

It would be nice to be able to have a debug trace option to view what dependancies are being injected. With that I would have seen that nothing I had done was being injected.

That's actually a great point. It will slow down things a bit, but for tracing this doesn't really matter much. I'll add this point to the list of options to consider for the 3.0 RTL revision. This revision is small though (so mostly breaking changes which were postponed and necessary changes due to features added to the designer). I think this will likely make the cut as it's beneficial for development and not some fancy 'it would be nice to' feature, but I can't guarantee anything, as the time we have for 3.0's RTL revision is limited (a month or so). If it's not added directly, it will be added in a future version. Thanks for the suggestion

Ok Thanks.