Is your feature request related to a problem? Please describe.
My application projects have a "Publish Profile" generated by Visual Studio 2019. These files can be used with the dotnet publish command to deploy production-ready executables to the configured target (local folder, IIS, Azure, etc.). I would like to execute this command through Nx to enable a CI/CD workflow that includes nx affected --target=deploy.

Describe the solution you'd like
A new executor that simply wraps the dotnet publish command will be sufficient for the desired workflow. It should be very similar to the existing build executor. It should also be able to pull configuration from the environment, such as deployment credentials.

Describe alternatives you've considered
The Nx run-commands executor allows for the basic construction of the dotnet publish command, but the variability of the arguments was too much to encode into the workspace.json file.

Additional context
I have previously worked on a similar feature for my workspace's private use. Deployment secrets were handled by allowing shell syntax in the executor's configuration, and then using environment variables as the properties' values. For example,

"options": {
  "PublishProfile": "MyPublishProfile",
  "UserName": "%MY_USR%",
  "Password": "%MY_PSW%"
}

In general, there may be more than one Publish Profile, and deployment credentials may be needed to connect to a remote machine.

Describe the bug
When using the Nx flag --skip-cache, all dotnet tests fail with the following error.

MSBUILD : error MSB1001: Unknown switch.
Switch: --skipCache

To Reproduce
Steps to reproduce the behavior:

1. Create a new Nx workspace.
2. Create a new app with a test project using nx generate @nx-dotnet/core:app --name=app --language=C# --template=console.
3. Run the (empty) test project with nx run app-test:test --skip-cache.
4. The tests will fail with the above error.

Expected behavior
The tests should run normally, and the Nx cache is not used to replay old results.

Environment:

• OS: Windows
• Browser: N/A
• Version: 0.5.1
• Affected Packages: @nx-dotnet/core

Additional context
I am somewhat surprised that the --skip-cache flag is being passed to the executor, as it is an Nx flag and not an executor option. The intention is to run the tests without checking the cache for a previous run. This may be a bug with Nx that the global flag is being passed to all executors. If this behavior is intended, then the dotnet plugin will need to exclude the skipCache option when generating the dotnet client flags.

Something like this, either as a schematic or target:

nx g nx-dotnet/add-dependency <project> <nuget-package>
nx run <project>:add-dependency <nuget-package>

We're contemplating moving our existing .NET projects all into a single monorepo using nx; great work so far with nx-dotnet...!

For a given app, we might have multiple test projects - for example, we might have a test project which contains only unit tests, another which contains integration tests and another which contains acceptance tests:

• MyApp.Tests.Unit
• MyApp.Tests.Integration
• MyApp.Tests.Acceptance

I notice that the @nx-dotnet/core:test generator is hardcoded to create a test project named <app-name>-test - attempting to create another test project for the app fails due to the name already existing.

Could the generator be updated to allow the user to specify/override the "-test" suffix?

Note: admittedly, we could use the xunit Trait attribute to handle this scenario, but I would still prefer not to be constrained by a 1:1 ratio of app to test projects.

Angular CLI supports builders.json + collection.json instead of executors.json + generators.json. These should be supported by nxdoc.

Describe the bug
Get follow errors when running nx build after creating .net project using nx-dotnet

To Reproduce
Steps to reproduce the behavior:

1. Create a Nx react workspace
2. Generate a webapi .net project using nx-dotnet
3. Run nx build command
4. See error

Expected behavior
should build successfully

Screenshots

C:\Repos\test-nx-dotnet>nx build
Looking for project files at 'apps/test-service/**/*.*proj'
Looking for project files at 'apps/test-service-test/**/*.*proj'
nx-dotnet encountered an error parsing dependencies for test-service-test
(node:12964) UnhandledPromiseRejectionWarning: TypeError: builder.getProjectGraph is not a function
    at Object.processProjectGraph (C:\Repos\test-nx-dotnet\node_modules\@nx-dotnet\core\src\graph\process-project-graph.js:19:20)
    at C:\Repos\test-nx-dotnet\node_modules\@nrwl\workspace\src\core\project-graph\project-graph.js:134:23
    at Array.reduce (<anonymous>)
    at updateProjectGraphWithPlugins (C:\Repos\test-nx-dotnet\node_modules\@nrwl\workspace\src\core\project-graph\project-graph.js:130:20)
    at buildProjectGraph (C:\Repos\test-nx-dotnet\node_modules\@nrwl\workspace\src\core\project-graph\project-graph.js:107:15)
    at createProjectGraph (C:\Repos\test-nx-dotnet\node_modules\@nrwl\workspace\src\core\project-graph\project-graph.js:71:26)
    at Object.<anonymous> (C:\Repos\test-nx-dotnet\node_modules\@nrwl\workspace\src\core\project-graph\project-graph.js:40:16)
    at Generator.next (<anonymous>)
    at C:\Repos\test-nx-dotnet\node_modules\tslib\tslib.js:117:75
    at new Promise (<anonymous>)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:12964) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a 
promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:12964) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Environment:

• OS: [Windows 10]
• Version [0.15.0]
• Nx [12.6.2]

Additional Context
generator config:

  "generators": {
    "@nx-dotnet/core:app": {
      "language": "C#",
      "tags": "type:api",
      "template": "webapi",
      "testTemplate": "xunit"
    },
    "@nx-dotnet/core:lib": {
      "language": "C#",
      "template": "classlib",
      "testTemplate": "xunit"
    }

Currently e2e / integration tests are only in place for the following 3 generators:

1. nx g @nx-dotnet/core:app
2. nx g @nx-dotnet/core:lib
3. nx g @nx-dotnet/core:project-reference

The existing tests are only partial, and all held in one file. They should be split up and new tests added for the new options (such as test project generation).

The following commands are missing e2e tests, and need to be added from scratch

1. nx g @nx-dotnet/core:nuget-reference
2. nx g @nx-dotnet/core:sync
3. nx g @nx-dotnet/core:init
4. nx g @nx-dotnet/core:restore
5. nx build my-app
6. nx test my-app-test
7. nx lint my-app
8. nx serve my-app
9. nx dep-graph / print affected

I definitely agree about installing tools being the path for getting this executor up and running.

I see something like this:

1. Init schematic is updated to create the tool-manifest, with some messaging about "Tool Manifest created for managing dotnet tools"
2. Tools are installed if needed at the time a schematic that would use them is used the first time.
   • In practice, this means that we can have this format tool, or the swagger cli tool later, or other tools be known by the package, but only installed if users care about them.
   • A process flow with this would look something like: User runs nx format my-api -> Executor checks for tool in manifest, installs if missing -> Executor checks that tool has been restored, reports error message otherwise -> Executor runs tool
3. Add a restore schematic (simple schematic, runs dotnet restore and dotnet tool restore)
4. Update init schematic to add nx g @nx-dotnet/core:restore to npm prepare scripts. Something like:

       const package = readJson(host, 'package.json')
       const prepareSteps = package.scripts.prepare?.split?.('&&')?.map?.(x => x.trim()) ?? [];
       if (!prepareSteps.includes('nx g @nx-dotnet/core:restore')) {
           prepareSteps.push('nx g @nx-dotnet/core:restore')
       }
       package.scripts.prepare = prepareSteps.join(' && ')
       writeJson(host, 'package.json', package)

I'll create new issues for the tool management when I am home this evening.

After we get tool-mgmt in, this executor should be pretty quick to test.

Originally posted by @AgentEnder in #13 (comment)

Problem:

Nuget packages are managed within .csproj files, meaning different apps/libs in the same workspace might have different versions. This goes against single version principle, which Nrwl has defended many times in the Nx repo.

Use Case:

Users can run nx g nx-dotnet/app or nx g nx-dotnet/lib to generate a new dotnet cli app or class library.

Considerations:

• Optionally pass in project template?
• Should C# libs be prefixed? @nstudio/xplat for example prefixes nativescript apps or web apps with nativescript or web.
• These need to work with the dependency graph. If this works by default great, if not we will have to build it in.

E2E tests should be fixed, and new tests added for features that are missing e2e scripts.

publish-local should be able to be used with the .npmrc.local file to get package installation working correctly again.

Generated docs from nxdoc currently contain no info about default values or option choices from enum. These should be contained inside the markdown.

Describe the bug
When using the Nx Console UI the the nx-dotnet generators do show up in the list. But when selecting either of them nothing happens. No options are shown and the generator is not executed.

To Reproduce

• Ensure Nx Console extension is installed
• Use Nx Console to generate
• Select @nx-dotnet/core app

Expected behavior
After selecting the generator a page with all options of a given generator should show up.

Screenshots

Environment:

• OS: WSL (Ubuntu 20.04)
• Package (latest)

If no apps were affected by the build job then the entire workflow is marked as failed, since the deploy job depends on the artifact existing.

This could be corrected by not triggering the deploy step if no artifacts were published.

Is your feature request related to a problem? Please describe.
Many of my projects were migrated from a previous (non-Nx) repository and did not originally contain tests. I migrated the projects using the app/lib generators and setting the test template to None. Later, I tried to create tests for one of these migrated projects, but I could only choose app or lib. Either of those options would require me to override the default test template with None (to avoid a test of a test project), and the resulting project was missing the test executor.

Describe the solution you'd like
A new generator that creates test projects would simplify the process significantly. The generator should ask for a test template (excluding None) and target project. It should behave similarly to the app/lib generators by creating a project of the chosen type named target-test and create a reference from target-test to target. This project should be created in the same directory as the existing target project.

Describe alternatives you've considered
The only feasible alternative is to create the project using the app/lib generators, manually adding the project reference, and manually adding the test executor.

Describe the bug
When running nx test --project my-project --collect:"XPlat Code Coverage" the collect parameter is passed to dotnet test without the quotes resulting in an MS Build error:

MSBUILD : error MSB1008: Only one project can be specified.
Command failed: dotnet test MyProject.csproj --collect:XPlat Code Coverage

To Reproduce
Steps to reproduce the behavior:

1. Create a .NET app
2. Add code coverage
3. Run nx test --collect:"XPlat Code Coverage"

Expected behavior
Expect parameters to be passed to dotnet test with the quotes such as

dotnet test MyProject.csproj --collect:"XPlat Code Coverage"

Environment:

• OS: Windows 10
• Browser N/A
• Version 0.11.1
• Affected Packages @nx-dotnet/core

Describe the bug

• .gitignore is updated with duplicate entries when creating an app / library
• init schematic does not add gitignore entries for libraries
• init schematic is not compatible with custom workspace layouts

Is your feature request related to a problem? Please describe.
I recently migrated my workspace to Nx 12.5 and switched to standalone project configurations. When I added a new .NET project to my workspace, the new project used the old nx.json and workspace.json configuration.

Describe the solution you'd like
I would like a new option added to the app and lib generators that generates the project configuration in standalone format.

Describe alternatives you've considered
Alternatively, I could write my own wrapper generator/script that moves the project configuration after it has been written, or I use the Nx-official generator to migrate the newly created project into the new format.

Additional context
Generating project configuration in the new standalone format is a one-parameter change to addProjectConfiguration. The app and lib generators just need a new parameter which will be passed through to addProjectConfiguration.

https://docs.microsoft.com/en-us/nuget/quickstart/create-and-publish-a-package-using-the-dotnet-cli

Describe the bug
The output directory added to the csproj file after generating a new project does not follow the pattern used by official Nx plugins. The generator @nrwl/angular:application (for example) will specify an output path that is identical to the project root, other than a dist/ prefix.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Nx workspace
2. Generate a new .NET application with npx nx generate @nx-dotnet/core:app my-app --template console --language C# --test-template none
3. Open the generated file apps/my-app/MyApp.csproj
4. The OutputPath element specifies a path of ../../dist/my-app, which is missing the apps part of the original file path.

Expected behavior
The OutputPath element should have been ../../dist/apps/my-app to match the pattern of other Nx generators.

Environment:

• OS: Windows
• Browser: N/A
• Version: 0.2.0
• Affected Packages: @nx-dotnet/core

Additional context
When the project directory contains additional folder nesting (such as when the --directory flag is specified), the OutputPath element contains the extra directories, but it still does not contain the apps portion of the file path. The output path given in workspace.json never includes extra directories and, as a result, is sometimes inconsistent with the csproj file.

If the output path follows the standard Nx pattern, then the outputs property of the workspace.json file becomes unnecessary, as the explicit and default values are the same. It is worth nothing though that @nrwl/angular will explicitly specify the output path, even when it matches the inferred default.

Describe the bug
Files are actually generated when I use nx-dotnet generators with Nx Console to preview my options.

To Reproduce
Steps to reproduce the behavior:

1. Open the Nx Console tab in Visual Studio Code.
2. Click on Generate.
3. Pick @nx-dotnet/core - app.
4. Specify any name.
5. Files are generated.

Expected behavior
No files should be generated when --dry-run is specified by Nx Console.

Screenshots

Environment:

• OS: Windows 10
• Editor: Visual Studio Code 1.55.2
• Nx Console version: 17.2.0
• Version: 0.4.1
• Affected Packages: @nx-dotnet/core

Describe the bug
The project doesn't run with the specific sdk specified in the global.json file.

To Reproduce
Steps to reproduce the behavior:

1. Create a project with net core 2 or 3.
2. Run the project with nx serve [project-name].
3. You will see a warning saying info about the support of a previous version to current.

Expected behavior
It should run the project with the specified version in global.json file.

Screenshots

Environment:

• OS: Windows 11
• Browser [e.g. chrome, safari]: Not apply.
• Version: Not apply.
• Affected Packages: Not apply.

Currently nx-dotnet is handling project references by updating nx.json.

This should be updated to use https://nx.dev/latest/angular/structure/project-graph-plugins

The xmldoc package adds additional newlines when manipulating the .csproj file to add the output path and msbuild task (not sure whether this affects Windows users, but definitely affects MacOS users). Although functionality is not impacted, the additional whitespace looks a bit unsightly, especially when creating xunit test projects, which bring in several PackageReferences.

For example:

<Project Sdk="Microsoft.NET.Sdk">
  
  <PropertyGroup>
    
    <TargetFramework>net5.0</TargetFramework>
    
    <IsPackable>false</IsPackable>
    
    <OutputPath>../../dist/apps/alerts-api-testing1234</OutputPath>
  </PropertyGroup>
  
  <ItemGroup>
    
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1"/>
    
    <PackageReference Include="xunit" Version="2.4.1"/>
    
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.3">
      
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      
      <PrivateAssets>all</PrivateAssets>
      
    </PackageReference>
    
    <PackageReference Include="coverlet.collector" Version="1.3.0">
      
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      
      <PrivateAssets>all</PrivateAssets>
      
    </PackageReference>
    
  </ItemGroup>
  
  <Target Name="CheckNxModuleBoundaries" BeforeTargets="Build">
    
    <Exec Command="node ../../node_modules/@nx-dotnet/core/src/tasks/check-module-boundaries.js -p alerts-api-testing1234"/>
    
  </Target>
</Project>

The documentation for xmldoc.toString() also states "that this is for debugging only! It is not guaranteed to always output valid XML."

Is it worth considering using a different XML parsing package? I've had a little play with fast-xml-parser - it reads XML into a JS object, then converts a JS object back to XML. For example:

  // read xml into object
  let xmlDoc = parser.parse(readFileSync(projectFilePath).toString(), {
    ignoreAttributes: false,
    parseAttributeValue: true
  });

  // manipulate object
  xmlDoc.Project.PropertyGroup.OutputPath = '../../dist/apps/an-example';
  xmlDoc.Project.Target = {
    '@_Name': 'CheckNxModuleBoundaries',
    '@_BeforeTargets': 'Build',
    Exec: {
      '@_Command': 'node ../../node_modules/@nx-dotnet/core/src/tasks/check-module-boundaries.js -p an-example'
    }
  }

  let j2x = new parser.j2xParser({
    ignoreAttributes: false,
    format: true,
    supressEmptyNode: true
  });

  let newXmlDoc = j2x.parse(xmlDoc);

The contents of newXmlDoc will be similar to:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <IsPackable>false</IsPackable>
    <OutputPath>../../dist/apps/an-example</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1"/>
    <PackageReference Include="xunit" Version="2.4.1"/>
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.3">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
    <PackageReference Include="coverlet.collector" Version="1.3.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>
  <Target Name="CheckNxModuleBoundaries" BeforeTargets="Build">
    <Exec Command="node ../../node_modules/@nx-dotnet/core/src/tasks/check-module-boundaries.js -p an-example"/>
  </Target>
</Project>

https://devblogs.microsoft.com/dotnet/how-to-create-your-own-templates-for-dotnet-new/

• #23 Ability to generate .NET project templates
• #24 Ability to publish .NET project templates
• Ability to use custom .NET templates. (this works by default, since we fall back on .NET CLI)

Describe the bug
*.spec.ts files are included in the @nx-dotnet/core package. I noticed them for the generators.

To Reproduce
Steps to reproduce the behavior:

1. npm install --save-dev @nx-dotnet/core
2. Look in node_modules/@nx-dotnet/core/(...)

Expected behavior
No test suites are included in an NPM package.

Environment:

• Version: 0.4.1
• Affected Packages: @nx-donet/core

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/tools/dotnet-aspnet-codegenerator?view=aspnetcore-5.0

This functionality already exists but appears to be only implemented by linter plugins to ESLint or TSLint.

We have moved 50+ .NET projects over into a monorepo using nx-dotnet, but we now fear that it might become a monolith/ball of spaghetti if we cannot impose constraints on which apps can depend on which libraries.

Is there a solution for this?

Hi,

thank you for integrating .NET with NX.
Currently, I am evaluating this plugin for our project.

Seen Behaviour

Generating Apps and Libs works as expected.
I am also able to link a library to an application, modifying the .csproj-File.

Unfortunately, Rider does not recognize generated libraries as .NET projects.

Question

Can you provide some guidance how the correct setup should look like?

Current Workaround

I added the solution file manually to make Rider aware of generated projects.

# Here is what I did
dotent new sln # generates nx-dotnet-playground.sln
dotnet sln add apps/api-functions
dotnet sln add apps/api-functions-test
dotnet sln add libs/mylib

# close Rider
# open Rider by double-clicking nx-dotnet-playground.sln in Explorer/Finder.

Demo Repository

You can see my work at: https://github.com/GregOnNet/nx-dotnet-playground

Thanks in advance for your help.

Versions 1.3.0 and 1.3.1 produce the following executing command for @nx-dotnet/core:serve (which exits immediately with Exit Handler Called):

dotnet watch --project D:\path\to\project.csproj run --configuration Debug --runtime win-x64

When rolling back to 1.2.0 the correct command is generated and executes ok:

dotnet watch run --project D:\path\to\project.csproj --configuration Debug --runtime win-x64

https://github.com/dotnet/format

Describe the bug
When generating a library, the newly-added section of workspace.json includes a serve target. This target invokes dotnet run under the hood, which is not supported for library projects. The serve target should only be added to application projects.

To Reproduce
Steps to reproduce the behavior:

1. Create a new Nx workspace
2. Generate a new class library with npx nx generate @nx-dotnet/core:lib my-lib --template classlib --language C#
3. Open workspace.json and find the section for my-lib.
4. The architect key includes a serve target, which will always fail when run.

Expected behavior
A serve target should not be included for library projects. Only the build target should be scaffolded (plus a test target if a test template was specified).

Environment:

• OS: Windows
• Browser: N/A
• Version: 0.2.0
• Affected Packages: @nx-dotnet/core

Use Case

Generated apps should be able to add references to generated libraries. This could look like either:
nx g nx-dotnet/add-reference <target> <source>
or
nx run <target>:add-reference <source>

Considerations

• A warning at minimum should be thrown when trying to add a reference to another app
• Adding a reference to a project should add an implicit dependency to nx.json as below

{
    "projects": {
        "target-project" : ["source-project-a", "source-project-b"]
    }
}

Need to find someway to auto-generated docs, likely taking inspiration from nrwl/nx.

We should be able to install + publish .NET templates to a nuget feed.

See #12 for more info.

Describe the bug
When using MacOS, the nx dependency graph does not show dependencies on class libraries from apps.

To Reproduce
Steps to reproduce the behavior:

1. Create workspace
2. Create console application (nx generate @nx-dotnet/core:app Demo.App)
3. Create class library (nx generate @nx-dotnet/core:lib Demo.Lib)
4. Using an IDE, create a class in Demo.Lib and consume it in Demo.App - ensure the IDE adds a project reference from Demo.App to Demo.Lib.
5. Look at the dependency graph (nx dep-graph)

Expected behavior
The dependency graph should show a dependency on Demo.Lib from Demo.App.

Environment:

• OS: MacOS
• DotNet SDK: 5.0.100

Additional context
After some investigation, this problem appears to be caused by the fact that the DotNet CLI writes project reference paths into the *.csproj files using backslashes, for example:

  <ItemGroup>
    <ProjectReference Include="..\..\libs\demo.lib\DemoLib.csproj" />
  </ItemGroup>

If you manually edit the *.csproj file and convert the backslashes to forward slashes, then the dependency graph works as expected:

  <ItemGroup>
    <ProjectReference Include="../../libs/demo.lib/DemoLib.csproj" />
  </ItemGroup>

Strangely, if you create a unit test project for the app when prompted by nx, then the dependency from the test project to the app works fine despite the use of backslashes - maybe this works because it doesn't have to go up a folder to the libs folder?:

  <ItemGroup>
    <ProjectReference Include="..\demo.app\DemoApp.csproj" />
  </ItemGroup>

It looks like the DotNet CLI creates project references with backslashes; I wonder whether there's an issue with how resolve is calculating the paths here: https://github.com/nx-dotnet/nx-dotnet/blob/master/packages/utils/src/lib/utility-functions/workspace.ts#L60

I've a question.

Why it doesn't use the dotnet watch run command to run the project instead of chokidar?

Using dotnet give the command the responsibility for refresh the project, and it could remove a dependency.

1. During installation check if .NET Sdk is installed
   1. Check against package.json sdk version
   2. Warn if mismatch
2. Supply link to current version

Currently, all applications and libraries are generated with the PascalCased version of the name given by the user, without any prefix or scoping. At minimum, I would like to see the organization name at the start of the project name/namespace, similar to the existing npmScope configuration used with JS libraries. For example, a library named my-lib with an npmScope of my-org should use the C# namespace MyOrg.MyLib.

Extending this idea further, it may be useful to have additional workspace-specific scopes as intermediate segments in the namespace. Using the Nrwl Airlines example, the library named shell within the booking scope would be named Nrwl.Booking.Shell.

These two goals could be accomplished by reading the npmScope property from nx.json and parsing the folder path used to create the library. Alternatively, the namespace could be specified by the user exactly as they want it, without any inference from the generator.

Describe the bug
When generating a new library with the --directory flag, an extra dot is added to the project's name. This also applies to the corresponding test project.

To Reproduce
Steps to reproduce the behavior:

1. In a new Nx workspace, run the following command

nx generate @nx-dotnet/core:lib --name=my-lib --language=C# --template=classlib --testTemplate=xunit --directory=my-folder

2. Open the newly generated folder libs/my-folder/my-lib.
3. See that the name of the .csproj file is MyFolder..MyLib.csproj.

Expected behavior
The project's name should be MyFolder.MyLib.csproj with only one dot between the folder and project names.

Screenshots
The following screenshot shows a real-world example of this bug, using Nx Console to run the lib generator.

Environment:

• OS: Windows
• Browser: N/A
• Version: 0.10.3
• Affected Packages: @nx-dotnet/core

This could potentially use an external dependency such as dotnet-serve

dotnet cli tool does not currently support sql projects. To patch this gap we could use https://github.com/rr-wfm/MSBuild.Sdk.SqlProj

dotnet new {template} allows for installing custom templates. We should provide a generator that would house these in the mono-repo.

https://devblogs.microsoft.com/dotnet/how-to-create-your-own-templates-for-dotnet-new/

For more info see #12

Something like:

nx g @nx-dotnet/typescript:interfaces --target="[lib / app name]" --source="[lib / app name]" [--sourceNamespace="Example.CSharp.Project"]

would be perfect to keep typescript interfaces for API DTO's or entities on the front end in sync with the back end.