OData / odata.net

ODataLib: Open Data Protocol - .NET Libraries and Frameworks
https://docs.microsoft.com/odata
Other
686 stars 349 forks source link

T4 templates from "OData Connected Service" does not work #1049

Closed drwatson1 closed 6 years ago

drwatson1 commented 6 years ago

When I generate a client code with "OData Connected Service" (0.3.0) extension with unchecked "Whether to include the T4 files into this project" option all works as expected. But if I check the "Whether to include the T4 files into this project" to include templates for some customization I get an error:

Error   CS0234  The type or namespace name 'EdmxReader' does not exist in the namespace 'Microsoft.OData.Edm.Csdl' (are you missing an assembly reference?)

Assemblies affected

Reproduce steps

Expected result

Client code must be generated.

Actual result

Reference.cs contains:

ErrorGeneratingOutput

Error:

Error   CS0234  The type or namespace name 'EdmxReader' does not exist in the namespace 'Microsoft.OData.Edm.Csdl' (are you missing an assembly reference?) ClassLibrary1   c:\users\xxx\source\repos\ClassLibrary1\ClassLibrary1\Connected Services\OData Service\Reference.cs

Additional detail

If I replace Reference.ttinclude with the latest version from here I get an another error:

Error       Compiling transformation: The type or namespace name 'CsdlReaderSettings' could not be found (are you missing a using directive or an assembly reference?)

So it doesn't work too.

drwatson1 commented 6 years ago

I don't no what had happened but now I got another error:

(1) Compiling transformation: The type 'Func<,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
(2) Compiling transformation: The type 'XmlReader' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Xml.ReaderWriter, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
(3) Compiling transformation: Argument 1: cannot convert from 'System.Globalization.CultureInfo' to 'string'    

After I added into the Reference.ttinclude these lines:

<#@ Assembly Name="System.Runtime.dll" #>
<#@ Assembly Name="System.Xml.ReaderWriter.dll" #>

The first two errors are disappeared. And now I have only cannot convert from 'System.Globalization.CultureInfo' to 'string' error. But I can't find that line of code...

drwatson1 commented 6 years ago

I found a very curious lines of code in ttinclude (lines 2350 and 2357 in my case):

this.Write(string.Format(CultureInfo.InvariantCulture, global::System.Globalization.CultureInfo.CurrentCulture, format, args));

I think it is a very old and buggy code. After fixing it I've got a generated cs file but it didn't compiled because of line return global::Microsoft.OData.Edm.Csdl.EdmxReader.Parse(reader); in method private static global::Microsoft.OData.Edm.IEdmModel LoadModelFromString().

When I replaced ttinclude with the latest version of this file from here I've got The type or namespace name 'CsdlReaderSettings' could not be found (are you missing a using directive or an assembly reference?) again and some other errors...

I give up :)

Please, help me!

RiPont commented 6 years ago

I ran into the same issue.

It looks like EdmxReader was renamed to CsdlReader. I changed it in the generated code, and now I can compile. I don't like the idea that I have to change the generated code to get it working.

AlanWong-MS commented 6 years ago

The ttinclude under the Connected Services repo should be updated to encompass the latest changes from ODL.

Since it turns out that this issue is related to that project, could you please open the issue under that repo? The team currently does not have resource allocated to fixing bugs under that project but you're more than welcome to open a pull request to help fix it. Thanks!

Marking this closed in favor of having one opened under OData Connected Service.

kitsu commented 6 years ago

Same problem using the OData v4 Client Code Generator (which is part of this project?). Following directions here via a broken link in the current OData docs I upgraded the automatically added Nuget packages, which then broke my build.

If you guys are going to release an update to a library that breaks the recommended/maintained/frequently-referenced build tool then you should probably release an update for the tool too.

Also, what is with the Lab/Connected Services thing? Is it unmaintained? Is it going away? Being integrated? As a new user trying to ramp up on OData.net everything seems to be in shambles. It would be really nice to at least have a clear roadmap of what is going on with OData support on DotNet.

AlanWong-MS commented 6 years ago

@kitsu, thanks for pointing out the broken link in the doc, I submitted a PR to fix it.

I read over the doc and you're right, it made an inaccurate assumption that something wasn't going to break if you updated to latest released--for the most part, the blog post is still valid in its instructions. I recently made several changes to the tool and we are planning to release a new version that's compatible with ODL 7.x. From this point forward, there will be a new Client Code Gen release with each library version update based on the way I set up the builds. You can follow the latest updates at #731.

Regarding Lab/Connected Services, we currently don't have resources allocated to it. I'll take your feedback to the team regarding that extension.

To shed some light, the OData project had been transferred from one team to another one, and we're trying to get access to the necessary media outlets (logistics is kind of a nightmare), including our blogs, to better communicate our roadmap.

kitsu commented 6 years ago

Okay, good to hear.

I do think OData is an interesting platform, and the parts of the DotNet OData stack that are in-place are very compelling. I will continue my struggles, and look forward to future updates!

ghost commented 6 years ago

Same issues here.

ghost commented 6 years ago

Solution is next:

  1. Make sure you are on Framework 4.6.1
  2. Add Nuget Extensions & Tools for Connected services
  3. Connect the service to D365FO which will use T4
  4. Compilation or reference errors occur;
  5. Add Microsoft.Data.OData version 5.8.3 and add Microsoft.Client 7.4.4 through Nuget.
  6. Also verify Microsoft.Edm and Microsoft.Odata referenced to your project
  7. Now rename EmdlReader to CsdlReader in the generated project.
  8. Now you can compile.

Can happen that on point 7 your VS crashes, better is to use NotePad outside VS.

stefanbalan commented 6 years ago

I just lost an entire day with this... :(

Using "OData v4 Client Code Generator" extension, version 7.5.0, with "Microsoft.OData.Client" nuget package version 7.5.0! Yet running the template resulted in quite a few errors like CsdlReaderSettings does not exist in namespace Microsoft.OData.Edm.Csdl and others that suggested the libraries the template was written for and the libraries in the project did not match.

Turns out, because I had the "OData Connected Service" extension installed, which contains (an old version of the same t4 template AND) the old OData Client libraries in "c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\Extensions\abcdefghi.abc"... Visual Studio was picking those up instead of those present in the project...

In short: you can not have both installed...

RayKoopa commented 6 years ago

It looks to me the Connected Service is the latest, not the Client Code Generator.