C# generator includes unnecessary usings in Operations files, causing compilation errors

[matthchr]

In our IOperations classes, when using an up to date version of AutoRest, I am seeing this change:

-    using System.Linq;
+    using Microsoft.Azure;
+    using Microsoft.Azure.Batch;
     using Microsoft.Rest;
     using Microsoft.Rest.Azure;
+    using Microsoft.Rest.Serialization;
     using Models;
+    using Newtonsoft.Json;
+    using System.Collections;
+    using System.Collections.Generic;
+    using System.Linq;
+    using System.Net;
+    using System.Net.Http;
+    using System.Threading;
+    using System.Threading.Tasks;

The issue is that using Microsoft.Azure and using Microsoft.Azure.Batch were added. By adding these usings (which aren't needed by the way), we now have ambiguous references in the generated code. Specifically, in the method signature: public async Task<AzureOperationResponse<IPage<NodeAgentSku>,AccountListNodeAgentSkusHeaders>> the NodeAgentSku type is flagged as duplicate because it exists in both the Microsoft.Azure.Batch namespace, and the Models namespace.

This paradigm has worked for us since we started using AutoRest -- is there a way to configure the code generator to omit the Microsoft.Azure.Batch using statement (which is causing these issues and isn't needed)?

[fearthecowboy]

Hmm.

How long ago (ie, what autorest version) was the last code generation made?

I'm surprised that it produces code that is ambiguous since it's a Roslyn based simplifier. If there is a conflict, it should have opted to use the full class names.

[matthchr]

We were using this previously: 1.0.0-Nightly20170209

You can run this file: https://github.com/Azure/azure-sdk-for-net/blob/psSdkJson6/src/SDKs/Batch/DataPlane/generate.cmd and reproduce the issue.

Maybe the fact that the conflicts are coming from the .sln which includes directories above the generated directory is the problem?

[fearthecowboy]

The SLN shouldn't be the problem. File selection happens from the csproj file.

That looks like it's probably a build from before we moved from Roslyn 1.3 to 2.0.

I'm going to have to dig into this-- the simplifier shouldn't be able to produce code that doesn't compile.

Can you add --disable-simplifier and see if those are still generated?

[fearthecowboy]

Yeah, this was the result of us bumping the Roslyn bits. It's "helping" by adding in explicit references when there are implicit references in place (ie, if your namespace is foo.bar.baz it adds usings for foo.bar and foo -- which are implicit (and implicit used namespaces don't cause ambiguity)

I'm going to add a directive to tweak that, it's going to show up in the 2.0 stable release in september.

I can give you a scripting workaround for now...

[olydis]

@dsgouda closing, I assume you have confirmed that the above specific case is fixed? 🙂
@matthchr this will be available with the next AutoRest release (right after Ignite)

[dsgouda]

Yes sir!