What the ????

OK, so I wanted to take a scaled-down version of our model and try to duplicate another error, to prove I wasn't making things up.  I took an old project I had created to prove WCF and LightSpeed 4 work together, and updated it to the latest build.  When I tried to build the solution, I got the following error message:

The custom tool 'LightSpeedModelGenerator' failed. Unable to find resource 'Base.vm'

So I deleted the model and recreated it.  Same error message.  Like the title says, What the ????

Are there custom templates in play?  For example is it possible your old project pointed to custom templates at an absolute path and that absolute path is not there on your current machine?

If that doesn't spark anything then the quickest solution is probably to use Procmon or something like that to trace accesses to files named Base.vm -- that should give you an idea of where we are trying to load Base.vm from and whether this seems correct or not.

OK, I resolved the Base.vm issue by deleting the old DodoModel directory and everything under it, then recreating it from scratch (not really that big an ordeal).  Now I'm getting the following -- note, this is in the generated code, and TestResult derives from Entity<int>.  Obviously, there is something else going on that is not reflected in the error message as this is exactly how my working model is set up...

Ideas?

'DodoModel.TestResult._dateTime' is not marked with OptionalFieldAttribute, thus indicating that it must be serialized. However, 'DodoModel.TestResult' derives from a class marked with DataContractAttribute and an IsReference setting of 'True'. It is not possible to have required data members on IsReference classes. Either decorate 'DodoModel.TestResult._dateTime' with OptionalFieldAttribute, or disable the IsReference setting on the appropriate parent class.

Hi Dave,

You will get this error if your entity does not have a [DataContract] attribute applied. Check if you are referencing System.ServiceModel in the project where your model lives as this controls if we generate the DataContract markup.

Jeremy

That did it, that and the System.Runtime.Serialization library.

Funny, my example now works, but no matter what I did with code (context.Logger = new TraceLogger();, ... = new ConsoleLogger();), the trace output always showed up in the console.  So, I looked in the config file and found the line, just as described in the manual -- in the lightSpeedContexts section.  Not in system.Diagnostics, as I expected, but in the lightSpeedContexts section.

(For what it's worth, that section of the manual needs some expansion.  It really is not clear what section of the config file needs to be modified, or how to set up a destination for output of the TraceLogger...  I still don't know where that is going, but I need it -- the SQL is more than the Console will hold by default, and I'd like to send it to a file or Trace log instead of just spewing it out into a console session.)

Anyway, as a test, I commented out that line.  Nothing, no output anywhere, no matter what I set the line in code to be.  So, I tried setting the line in the config file to TraceLogger instead of ConsoleLogger.  Still nothing.  Zip, zilch, nada.

Going back to my production application, I modified my app.config to match the test program, and now I can get the tail end of the SQL I am interested in, spewed out to the console.  In order for this to be useful, I need to see more of the log, but at least now it's working.

I attached my sample solution so you can verify my observations.  It's a fairly simple test, and you really only need to populate the Testers table to have it return successfully, as the others are not used.

Dave

attachment?

Okay, it seems that the issue is that LightSpeed is writing to the global Trace object instead of using a particular TraceSource, which means it needs to be hooked up via the <trace> element instead of the <sources> element:

  <system.diagnostics>
    <trace>
      <listeners>
        <add name="xml" />
      </listeners>
    </trace>
  </system.diagnostics>

With this in place (and the loggerClass set to TraceLogger), I see LightSpeed output appearing in the WCF trace logger.

(By the way, it would not particularly help if we had used a TraceSource -- you would still have had to hook that up separately via a new <source> element.)

We'll obviously update the documentation to explain this -- using a mix of global Trace and specific TraceSources is clearly very confusing and we appreciate your bringing this to our attention!