Forked rework of Omnisharp generator-aspnet and additon of new template w/ options

[xtianus79]

Per our conversations here are the goods I promised...
https://github.com/xtianus79/generator-aspnet

*** UPDATE: 1 make sure when you install this you use npm install xtianus79/generator-aspnet and the generator name is aspnet-f5 to not interfere with another generator.

*** UPDATE: 2 - WARNING - When installing the "christian starter web template" make sure to be in the directory where you want your project installation to take place... i.e. projects/yourAppHere

*** UPDATE 3 - finished functionality of distribution folder... Added mkdir for includes and wwwroot/dist in the "christian starter web template." This will allow for the use of a _header.cshtml and _footer.cshtml to be calling into the _Layouts.cshtml for awesome functionality of bower insertions and concat and minify on project completion/publish.

*** UPDATE 4 - Removed Bower:Install functionality because it wasn't playing nice with wiredep. Wiredep allows for the automatic injection of bower dependencies into your html or cshtml files directly. Replaced funtionality of Bower:Install with seperate copy and clean grunt tasks. Now the folder structure in the wwwroot/lib mimics that of bower_components minus unnecessary files and folders. As a result, there is no need to use "exportsOverride" as the file path will be the same as where it came from.

*** UPDATE 5 - Fixed up some issues with grunt tasks so grunt bower-install runs after project is installed or kpm restore is ran. Both watch servers on port 9000 / dist 9001 work for index.html and ports 5001 work for k web command. Fixed issue for installation error on MAC OS X because of absolute file paths...

I will wait to see what is decided from the .net team for implementation of pull requests and listing other generators like this one.

The last update will be the publishing of the package to npm and change in readme file to reflect capabilities and changes.

*** Keep in mind. I believe the entry folder should be the name of your project as this gives the ability to run npm install & bower install after configuration. You will notice this when you choose "Christian's" template.

*** When running my template (from a folder inside of the projects directory) you will obtain a series of prompts. For now just hit enter (even for the project name) and it will install all of the defaults.

At the very end of the installation you will have everything installed... To test apply grunt in your CLI and you will notice that a series of events happens such as Bower:install, compile sass, copy, clean, bower-install, watch and more!!! there are many other commands as well.

*** a before distribution html playground setup on localhost port 9000 will allow for quick css / sass edits to be done and seen in realtime... no need to even refresh the browser.

*** bower install injects automagically bower packages into your project

*** The purpose of this is refined front-end work flow for Foundation or any other bower integration you can think of.

*** Lastly, I am not done with this as the very last thing I need to do... I am going to parse out the extra _Layout.cshtml into header and footer .cshtml such that it can be placed right into the real Layout.cshtml and will thus be automatically updated when working on the project above.

****** One noticeable bug from VS 2015 preview is that the gruntfile.js hangs when all of my options are selected. They are written correctly and all of them work in command line. to aleviate the issue I have commented out grunt task called dist, which is the final concat and minification of the project. <<< Very useful.

here is a link to the file.

https://github.com/xtianus79/generator-aspnet/blob/master/templates/projects/christian/_gruntfile.js

[xtianus79]

*** UPDATE: 1 make sure when you install this you use npm install xtianus79/generator-aspnet and the generator name is aspnet-f5 to not interfere with another generator.

[xtianus79]

*** UPDATE: 2 - WARNING - When installing the "christian starter web template" make sure to be in the directory where you want your project installation to take place... i.e. projects/yourAppHere

[sayedihashimi]

I haven't had a chance to try this yet (I'm traveling). On email one thing that I asked was to see if you could investigate default behavior of popular generators. I'd like for whatever we do to be in line with what others are doing so that we can provide a consistent experience.

[xtianus79]

@sayedihashimi Sure I would be glad to share this with you.
Here are the top generators and their directions or assumptions that you are already in the directory you are building your project from.
This is based on stars, downloads and name recognition.

#1 https://github.com/yeoman/generator-angular --> run yo app in directory
#2 https://github.com/DaftMonk/generator-angular-fullstack --> run yo app in directory
#4 https://github.com/Swiip/generator-gulp-angular --> run yo app in directory
#6 https://github.com/diegonetto/generator-ionic --> run yo app in directory
#9 https://github.com/yeoman/generator-webapp --> assumes you are in the directory - run yo app
#12 https://github.com/yeoman/generator-backbone --> run yo app in directory
https://github.com/yeoman/generator-ember --> run yo app in directory

The reason why IMO and assumptions that this makes the most absolute sense is that you are installing and running actions from that directory - automatically. for example this line of code will install bower and npm packages automatically.

if (this.templatedata.grunt) {
        this.on('end', function () {
            this.spawnCommand('grunt', ['bower-install']);
        });
    }

[sayedihashimi]

Thanks for the info and links. I will try the generator in the next day or so.

I also found that the generators from yeoman https://github.com/yeoman have this same behavior, so that leads me to agree with you. I'd like to hear what others think.

I think your brining up two issues here.

• Make they folder name optional
• Run grunt/gulp/bower automatically at the end of the generator.

For the running grunt part, do you know if the other generators do this? In the beginning of this project we would kick off kpm restore automatically. We received feedback that was annoying. Users wanted to have a chance to modify dependencies before a restore. This feels like we might get the same feedback on grunt.
In VS we do kick off a restore but that's after you project is created/loaded and executes in the background.

Thanks for taking the time to do this I really appreciate it. We (me at least) are not yeoman experts so we are all learning together.

[xtianus79]

@sayedihashimi I can't wait for you to try it because most of your concerns will be alleviated. In fact, we could implement the kpm restore after build the same way I implemented a grunt function.

To your 2 issues/concerns... The folder name is optional in my rework based on these 2 parameters.

first, if the template requires no folder generation then this property can be excluded.

    if (!this.type == 'christian') {
        this.mkdir(this.applicationName);
    }
    switch (this.type) {

second, instead of using applicationName as the app name for the default prompt you can parse the current folder you are in and hit return to simply set that name for whatever reason (if you're in the folder there might not be a purpose but it's there) or enter in your name if you are per se not in the current folder structure...
that is illustrated with this code here.

    var prompts = [{
        name: 'applicationName',
        message: 'What\'s the name of your ASP.NET application? Default =',
        default: '' + process.cwd().split(path.sep).pop() + ''

so in the end the folder name is optional and if you're in the path then you're good to go.

for the next concern yeoman has this.installDependenicies built in and this allows for the functionality at the end to run bower and grunt. I also wrapped this to in an if statement from a function that prompts the user in the beginning if they want this done or not. This is conjunction with the code I show you above. The same could be done for kpm restore I presume. All in all, there are about 5 questions, in my template that help setup the build process for the user.

code below of reworked end function. along with the code written in a previous comment.

When you get back let me know what you think. In the end I think it will make a lot of sense to run the templates this way. A lot more choices and room for others to build templates on top of the rework.

end: function () {
    if (this.templatedata.grunt) {
        this.installDependencies({
            bower: true,
            npm: true,
            skipInstall: false,
            callback: function () {
                console.log('\r\n');
                console.log(chalk.bold.red('==================================================================================='));
                console.log(chalk.bold.yellow('  Everything is ready!'));
                console.log(chalk.bold.red('==================================================================================='));
                console.log('\r\n');
                console.log('  Your project is now created, you can use the following commands to get going');
                console.log(chalk.green('    kpm restore'));
                console.log(chalk.green('    kpm build'));
                console.log(chalk.green('    k run') + ' for console projects');
                console.log(chalk.green('    k kestrel') + ' or ' + chalk.green('k web') + ' for web projects');
                console.log('\r\n');
                console.log(chalk.bold.red('==================================================================================='));
                console.log(chalk.bold.yellow('    Type [grunt] = default task command'));
                console.log(chalk.bold.red('==================================================================================='));
            }
        });
    } else {
        this.log('\r\n');
        this.log(chalk.bold.yellow('    Run this command -> [cd ' + this.applicationName + '] to enable the commands below'));
        this.log('\r\n');
        this.log('  Your project is now created, you can use the following commands to get going');
        this.log(chalk.green('    kpm restore'));
        this.log(chalk.green('    kpm build'));
        this.log(chalk.green('    k run') + ' for console projects');
        this.log(chalk.green('    k kestrel') + ' or ' + chalk.green('k web') + ' for web projects');
        this.log('\r\n');
    }
}

[xtianus79]

*** UPDATE 3 - finished functionality of distribution folder... Added mkdir for includes and wwwroot/dist in the "christian starter web template." This will allow for the use of a _header.cshtml and _footer.cshtml to be calling into the _Layouts.cshtml for awesome functionality of bower insertions and concat and minify on project completion/publish.

[sayedihashimi]

Thanks I will review today and comment back. Sorry for the delay, I'm on vacation with family.

[xtianus79]

@sayedihashimi sounds good. hope you like it...

[peterblazejewicz]

I also found that the generators from yeoman https://github.com/yeoman have this same behavior, so that leads me to agree with you. I'd like to hear what others think.
I think your brining up two issues here.
Make they folder name optional

In my opinion the generator-aspnet is a multipurpose generator - kind of Suisse Knife. Here - just like in VS - we can create multiple projects within a single top directory - within single solution. I like idea of using similar approach when creating a project between generator and VS tooling UX.
So I'm able to quickly scaffold three related projects within a single top directory:

• web
• class library
• web api

I've used to create projects like above within a single solution project at my work with current VS2013 tooling - so I find it really useful that I could translate that experience to generator.
That's not possible with other generators.

[xtianus79]

@peterblazejewicz So you agree that the projects should be deployed from within the directory. From you're example it would make sense for the subgenerators too yes?

[peterblazejewicz]

No, I'm not agree - have you used VisualStudio to generate different projects within a single solution? Your generator uses Foundation, have you used their foundation-cli tool? Does it make assumption about being in target directory?
https://github.com/zurb/foundation-cli
There are different approaches here and one currently used is not invalid one.

[xtianus79]

@peterblazejewicz I am confused by this statement "have you used VisualStudio to generate different projects within a single solution?" How would that change if you would just deploy in the directory you are in?

[peterblazejewicz]

@xtianus79
I meant: I appreciate sharing common UX patterns between tools - does it sounds clear? I appreciate that there could be a common path, UX pattern shared between VisualStudio and open source tools - as it would really help people.

[peterblazejewicz]

@peterblazejewicz I am confused by this statement "have you used VisualStudio to generate different projects within a single solution?" How would that change if you would just deploy in the directory you are in?

In VisualStudio I create a project choosing template and providing a name - the project directory is created and filled with code.
In generator I create a project choosing tempalte and providing a name - the project directory is created and filled with code.
Does both above statements are about the same UX pattern? Are you able to spot similarity?
Generator Angular does not create a project, it just takes (and most of genetors) directory name (or name from package.json) and spills it into generated Angular files - but optionally letting users to override that behavior. This as appName argument will only change content of templates, configs, etc, without a change of parent folder. In C# that's not a case - sometimes your parent directory name is crucial for namespace - correct me if I'm wrong. These could be changed recently, but I think that folder names are still crucial in C#.

[xtianus79]

@peterblazejewicz maybe I am confused from this point of view. Let me explain what this rework does. It accomplishes two things.

1. Is simply my template which yes uses foundation among many other things.
2. it proposes a different methodology for deploying projects/applications... The 2nd part is important for my template, and hopefully many others, to be able to generate fully functionally working projects upon deployment. There are prompts and parameters that make for a specific template being build per the users request.

I don't get how that coincides with what you are saying?

[xtianus79]

@peterblazejewicz I think see what you're saying now... But I believe i have that covered. I have a question.

You say

in C# that's not a case - sometimes your parent directory name is crucial for namespace - correct me if I'm wrong. These could be changed recently, but I think that folder names are still crucial in C#.

But I have a question? Is there something in the generator that C# uses to identify namespace with based on the application name you have chosen? If so that is great news because I left that parameter in there whether you are using the folder you are in i.e. application name or if you are in the project folder and then cd into the application after.

What matters most here is the design UX of the template - meaning was it supposed to be in the folder or outside of the folder.

To your next point of UX similarity between VS and Generator... I think about it this way. In VS if I choose a template and provide a name I am then dropped automatically into that template to do whatever it is that I need to do within that project. If this were possible then there wouldn't' be an issue but that is not possible with a Yeoman generator.

In fact, that is what this methodology would accomplish right? You are in the folder at the time the files are dropped into the project.

Plus, with this capability you are then able to run automatic bower and grunt commands | and potentially KPM commands that isn't even possible if you were to setup an app in VS.

So if I were comparing UX I would have to say that having the generator fill the project from the directory it is in is exactly how the VS currently works. Plus with more capabilities.

[sayedihashimi]

Thanks for all the comments and the sample that you created.

Let's take a step back and discuss principals. I'm proposing that we follow the following principle.

generator-aspnet principles

• We should be consistent with the _Visual Studio content_. Meaning that you can create equivalent project from either VS or generator-aspnet. For generator-aspnet, we can have a broader set of options since it's command line based, but users should be able to create the same projects.
• We should be consistent with the _yeoman user experience_. Meaning that users who are familiar with yeoman will find the generator-aspnet generators to be consistent with other generators.

We've already achieved the first goal of being consistent with VS project templates.

Regarding point 2, @xtianus79 has a good list of some of the most popular generators which do have the application name as optional. In addition to that I tried the generators created by yeoman themselves https://github.com/yeoman. They all have the application name as optional. You can specify a name and then that folder will be created. They also default to displaying the name of the current folder as the default name. So if you want your project created in that folder you hit enter, and if you want to create it in another folder you give the name at that time.

Some of the generators are smart with the application name, for example generator-generator which has a naming convention of generator-<name>. I created an empty folder named generator-sayedsample and when I invoked the generator it displayed sayedsample as the name of the generator. If you give another name like sayedfoo it will create a new folder named generator-sayedfoo.

Based on that I believe that we should switch to having application name as optional. I have some comments about the specific prompting that was in the sample, but I'll hold off on those until we close on the larger question.

@spboyer @peterblazejewicz thoughts?

I'd also like to see if @shanselman has thoughts here.

FYI I believe that @spboyer, @xtianus79 along with myself will be at the Orlando Code Camp let's get together and discuss in person if possible as well as here.

[spboyer]

A lot to chew on here.

First, all generators are opinionated and any implementation can range from being very generic to very specific depending on the goals.

As @sayedihashimi mentioned the 2 goals of generator-aspnet, I believe we have been trying to keep to these. I don't think that there is an issue with having an option of creating or not creating a directory with the appname. We just need to decide what the default behavior is and implement it.

As far as the extended solution that @xtianus79 has implemented in his fork as the "christian" type, this in my opinion is a specific and extended implementation of a build or CI process using minification, foundation, jade etc.

If these are additional options that should be made to the developer, there are more presentable ways to offer them. generator-ionic has a wizard like questions when asking for the cordova plug-ins with check boxes, and then adds the dependencies to the generated files for the selected items.

[xtianus79]

@spboyer you are correct that this is a specific and extended implementation of a build. However, like the generator-ionic generator my template uses a wizard to prompt the user into what options they specifically want in the framework of my template.

With that said, I believe some options that build grunt processes and add functionality would be on template level. Would you all agree with this?

For example, my template isn't just the notion of adding in foundation instead of bootstrap... But rather, it is a complete workflow with many options of functionality such as building your project, putting in additional bower libraries, compiling sass files (*in a very particular setup - this isn't just a foundation cli setup), and finally - publishing your project which minifies and concats your entire workflow.

With that said, that style of workflow is niche per se... The same setup could be done for boostrap or another css framework just not in this template. The reason being is that there gets to be a point where the complication of the flow or process is too great to just wizard or option out. I don't work with bootstrap so I wouldn't be the best person to create that template.

For things such as including font-awesome for other templates like the original starter web template is fair for a wizard and should be easy to implement. But for a template such as the generator that I have incorporated into the aspnet generator is most viable in it's own template and not in an optional/wizard type capacity.

I understand that it would be confusing to anyone that isn't immersed in foundation sass/scss process wouldn't know what this template is supposed to accomplish but a frontend person would greatly appreciate the VS integration.

So my suggestion based on I would suggest providing the framework for other templates or even forks to work seamlessly would the aspnet generator.

[xtianus79]

*** UPDATE 4 - Removed Bower:Install functionality because it wasn't playing nice with wiredep. Wiredep allows for the automatic injection of bower dependencies into your html or cshtml files directly. Replaced funtionality of Bower:Install with seperate copy and clean grunt tasks. Now the folder structure in the wwwroot/lib mimics that of bower_components minus unnecessary files and folders. As a result, there is no need to use "exportsOverride" as the file path will be the same as where it came from.

[xtianus79]

*** UPDATE 5 - Fixed up some issues with grunt tasks so grunt bower-install runs after project is installed or kpm restore is ran. Both watch servers on port 9000 / dist 9001 work for index.html and ports 5001 work for k web command. Fixed issue for installation error on MAC OS X because of absolute file paths...

I will wait to see what is decided from the .net team for implementation of pull requests and listing other generators like this one.

The last update will be the publishing of the package to npm and change in readme file to reflect capabilities and changes.

[sayedihashimi]

OK so @xtianus79, @spboyer and I met on Saturday to discuss and I have some thoughts to share with you.

Proposal

We believe that the generator-aspnet generators should provide the equivalent experience as to what is available in Visual Studio 2015. That way users can be sure that when they start with generator-aspnet that they are getting high quality templates and can share with Visual Studio users in a seamless fashion.

In addition to this we discussed the idea of the name of the project being optional or not. In the existing yeoman generators there is plenty of precedent for both having a required project name or being optional so there is no hard line one way or the other. Since the generators have been released they have behaved in the way that they do today, the name is required and that would create a new project folder. Also Visual Studio behaves this way as well. Because of that we should leave the project name as it is. If we hear feedback from the community indicating otherwise we can reconsider this decision.

Since the goal of generator-aspnet is to be equivalent to Visual Studio we should not try and shove in additional generators that strays far beyond what Visual Studio offers out of the box. Instead of this we believe that we should enable the creation of additional generators which can bring in such behavior. What we can do is to create a "family of generators" which users can discover and use to get the desired content. I believe that yeoman has been designed in this way as well. There is no reason to try and have one uber generator with all the options under the sky. I'm proposing that we create generators using the naming convention generator-aspnet-<name> for ASP.NET generators to make it easy to discover related generators. We can also promote related generators in this repository and potentially on omnisharp.net. There is plenty of precendent here as well, just take a look at the search results on npm for generator-angular

In this case @xtianus79 has created a generator which goes much farther than what Visual Studio has. This would be a good case to create a seperate generator, let's say generator-aspnet-xtianus79 or something more descriptive based on content.

These related generators can live anywhere. In some cases it will make sense to add them to the OmniSharp organization and in other cases in other repositories. If you've developed a related generator and you feel that it should be in the OmniSharp org please contact me and we can discuss it.

I have already added a section, related generators to the wiki home page. The only generator listed there is currently generator-csharp. generator-csharp doesn't meet the naming convention described above because they are not specific to ASP.NET. The goals for generator-csharp will be similar to generator-aspnet and have related generators with the naming convention generator-csharp-*.

If you are interested in creating a new related generator but you do not know where to start please reach out to me and I will help you get started.

Thoughts?

cc @shanselman @spboyer @xtianus79 @peterblazejewicz

[shanselman]

I love this idea. The naming thing is cool because it means I can get ones from people I respect, or from projects (generator-aspnet-nancy), or orgs. We should list them all in one place for discovery purposes!

[Mpdreamz]

+1

I love the idea of not having one big ass generator project that tries to generate everything under the sun.

There is no need to as well since yeoman allows for generators to be composed! 👍

http://yeoman.io/authoring/composability.html

I would personally love if we claimed both the generator-net-* and generator-aspnet-* npm prefixes e.g:

Generator	Use
generator-net	The only thing you need to install if you want to scaffold oldschool (portable) class libraries, console applications. Includes csharp, f# vb files generation including updating *.*proj and *.sln files.
generator-aspnet	allows you to scaffold aspnet5 console apps and web apps including mvc
generator-net-owin	allows you to generate owin class libraries or common self hosting options using i.e Nowin.
generator-aspnet-owin	allows you to start an owin aspnet5 project (subtle difference)
generator-aspnet-nancy	allows you to start an nancy aspnet5 project
generator-aspnet-jasper	allows you to start an jasper (fubu vnext?) aspnet5 project
ad infinitum!	go nuts

Not sure if we should also separate out languages from project types here though.

[Mpdreamz]

the big question here is what are the long term plans within MS, if project.json is the way to go forward for all projects we could eschew my proposed generator-net and rename the generator-aspnet to generator-net or probably less ambiguously to generator-dotnet.

[Mpdreamz]

We could list the most common base generators on the sexy new site and link to the wiki for even more community provided ones.

[peterblazejewicz]

@sayedihashimi
As I wrote, I'd like to have simple, focused generators, so I can quickly show to a group of people (say a team member from my work) what the generator is about. I'd like idea that I could show side-by-side features or content created by generator with content created by VS. And I could have a new team member without PC or without VS license (usage not covered by CommunityEdition). I'd really like to at least have similar content generated, quickly demonstrated and being productive.
I like the idea of small, focused generators, they are easier to maintain, develop and most important - in my opinion - to promote and discuss.
Thanks!

[xtianus79]

@shanselman @spboyer @xtianus79 @peterblazejewicz @Mpdreamz
I really like the idea of the proposed methodology of how generator variations will be handled. The main point will be to list them on a common directory.

@shanselman stated and I am I also love the idea

I love this idea. The naming thing is cool because it means I can get ones from people I respect, or from projects (generator-aspnet-nancy), or orgs. We should list them all in one place for discovery purposes!

Still, I want to keep something in perspective for everyone reading or weighing in on this topic. Generators are not something that is just simple. They are robust frameworks that if done well can make life simpler and more automated in a developers work process. I have used many generators and they do take a bit of a learning curve to get the most out of them. Most would say, including myself, after using them they wouldn't ever want to do without them.

With that said, I would ask the question and wonder how would it be handled in general the scope of each proposed generator.

For example, I have gone to great lengths to make sure the functionality of my generator keeps with the currently UX and functionality of the original generator plus my added template.

The reason why someone would choose my generator or someone else's is because they read the description and a particular generator appealed to them. Now, should that generator hold the same functionality of the original generator plus a template or certain functionality that has been added? Or is it ok if the generator does a very specific thing and omits the main generators functionality entirely or partially? Should that be in the description of the generator.

Again, it was important for me and will continue to be important for me to make sure that I sync my generator upstream to the aspnet generator and allow whomever should choose to use my generator still have all of the advantages and capabilities of the original generator i.e. sub-generators for example.

For my case I plan on just calling my generator aspnet-xf5 or if I plan on adding additional templates to my framework perhaps aspnet-xtianus will be more appropriate and I will have an npm package published soon based on this methodology. Most likely for the template inside I will call it foundation5... Foundation 6 will have certain aspects of angular built in and will likely need a major update.

In this way, and to the heart of @sayedihashimi and @shanselman 's point I will continue to update and create additional templates for my generator while keeping in an upstream communication with the original aspnet generator.

Once we come to an agreement, and I think we have... I would just like to hear a final decision... I would like to publish an npm package and setup the variations with my readme file and wikipage.

In my opinion anyone submiting a generator to be listed should have it published through npm with proper readme documentation so not to confuse the installer with npm someuser/generator-aspnet.

I am sure that in my case Foundation will be very happy I took the time to do this and promote this and aspnet on their site as well. They are very friendly folks!

[sayedihashimi]

FYI I have created a new wiki page based on my comment above https://github.com/OmniSharp/generator-aspnet/wiki/goals-and-related-generators.

With that said, I would ask the question and wonder how would it be handled in general the scope of each proposed generator.

That's the beauty of the approach. You can create generator-aspnet-* and you can take whatever approach you want. You don't need to consult anyone. If your generator becomes popular then we can all learn from it and apply that back to the other ones. Of course if someone reaches out we will work with them and provide the guidance that is appropriate. But we are not perfect and will get it wrong sometimes, so everyone should feel free to do their own thing as well.

With that said, I would ask the question and wonder how would it be handled in general the scope of each proposed generator.

It's up to that particular generator.

[xtianus79]

@sayedihashimi all in all I feel this is a great idea... I have learned a lot about VS in my time creating my version/extension of the aspnet generator.

With that said, I have buttoned up my generator and have tested it on both pc and mac and it works pretty well. I would like to submit it to the omnisharp/aspnet community

https://www.npmjs.com/package/generator-aspnet-xtianus

I can create a wiki for it on the aspnet wiki as well if you plan on having room for that. I have 2 readme files for the project that can be viewed for the main readme and the template specific readme here:

https://github.com/xtianus79/generator-aspnet/blob/master/README.md
https://github.com/xtianus79/generator-aspnet/blob/master/templates/projects/foundation5/README.md

The heart of what I have created is a not just a Foundation 5 framework for ASP.NET but a means to do frontend developement with bower and grunt while a .net developer creates his/her magic for the backend.

I hope everyone can appreciate the effort and look forward to adding additional template variations inside of the aspnet-xtianus package!

[sayedihashimi]

I thought I replied back to this a few days back but it looks like it was never posted.

For the short term I think what we can do to ensure that related generators are discoverable are:

• Ensure that related generators are named like generator-aspnet-* and generator-csharp-* for generators which are creating MSBuild based projects. That way everyone can search npm for generator-aspnet to find other generators.
• Update the readme.md to include a section about related generators. Note: this readme is also reflected on the https://www.npmjs.com/package/generator-aspnet. The readme.md for generator-csharp should also have a similar section once it gets updated.
• Update omnisharp.net to have a section on all the known generators

We also have a related generators section on the wiki https://github.com/OmniSharp/generator-aspnet/wiki, which anyone can edit. The readme and omnisharp.net sections are more important though as they will get more visibility.

I've already added the initial content based on generator-aspnet and generator-csharp. In the following places.

• https://github.com/OmniSharp/generator-aspnet/blob/master/README.md
• https://github.com/OmniSharp/OmniSharp.github.io/blob/master/index.md#yeoman-generators

For anyone developing a generator, after it's posted please send a PR to get a brief description of your generator added.

@xtianus79 can we close this now?

[xtianus79]

sure thing.