Next steps?

[sayedihashimi]

@dmccaffery @Muchiachio now that we have a repo we can use the issue tracker here for discussions.

One important thing that we should keep in mind is that we should safe guard the work that we do from breaking changes from the ASP.NET team. That way if there is a break we will know right away and can either fix it or bring it up with the ASP.NET team to get it fixed.

Some ideas for next steps

• [ ] Evaluate the current command line experience to see if we want to go with that or make changes to it
• [x] Figure out name of the NuGet package that we want to use and change project.json to use that name
• [x] Remove projects besides CodeGeneration and replace with NuGet package references.
• [x] Setup a CI build which will execute test cases on the latest released packages for scaffolding (or the latest from the scaffolding repo).
• [x] Setup up automated release process to get changes pushed to nuget.org/myget.org.

[dmccaffery]

Great Scott!

I'll get 2-4 done and submit a PR for it for review by the team tonight / tomorrow.

I'm familiar with both Travis-CI and AppVeyor, so that should be easy. I'm also familiar with KoreBuild, since I wrote a build system from scratch loosely based on it condo, so that shouldn't be an issue either.

The way that I normally handle NuGet publishing is to publish to a MyGet feed first, and then to promote from MyGet to NuGet when I'm more comfortable with a build. Does OmniSharp already have a feed on MyGet to which we can publish? If so, I vote for using that.

For the automated release, since we're completely OSS, we don't have a private build/release server like Team City or TFS/VSO release. I'd recommend handling the publish to a MyGet.org feed from the AppVeyor build, and then promoting from MyGet to NuGet when we're comfortable. I don't remember if KoreBuild has a macro for publishing to NuGet that uses an environment variable for the feed URI and ApiKey, but I have one within Condo that we can copy/pasta into this project if we want to release per build off the develop and master branches. Is there a better OSS alternative outside of supporting the publish off of a build directly through a KoreBuild process?

One other solution is to actually use Condo instead of KoreBuild, but that's a bridge that we should cross only if everyone is on the same page and feels the build system switch is rewarding enough for it to make sense.

[dmccaffery]

Oh, I should mention that the name of the NuGet package doesn't matter to me; I'll just pick something that makes sense based on OmniSharp conventions, and we can always hash it out as a team before accepting and merging the PR. I didn't mean to 'own' that piece of the puzzle myself; just wanted to make progress over the weekend. :)

[sayedihashimi]

To my knowledge OmniSharp doesn't have a myget feed.

Going to myget and then to NuGet sounds good.

AppVeyor also sounds good.

We can use any build system/process as long as it's easily understood by others without significant effort.

For the name of the NuGet package let's go with OmniSharp.Scaffolding for now, we can change it later if needed.

[dmccaffery]

Sounds good. I'm going to create a MyGet feed called "omnisharp" and make you a feed owner so it remains in control of the org.

Condo is very easy to use, but like KoreBuild, it isn't the easiest thing in the world to understand. It relies on Sake and the Spark view engine. It does have much better logging, though. I think it's best to stick with KoreBuild natively for now, unless it causes issues with semantic versioning and NuGet publishing that can't be easily solved. I know that MS uses TeamCity to manage all of that and KoreBuild is designed to look for and use variables defined by TeamCity; but I'll dig into that and report back if I feel we need an alternative.

[davidfowl]

Omnisharp does have a feed

[dmccaffery]

Even better; I'll test against my own feed, and someone else with access to that feed can update the feed uri and API key later.

[david-driscoll]

@dmccaffery I have access to add people to the feed if you need.

[dmccaffery]

@david-driscoll The OmniSharp feed doesn't seem to be published in the MyGet gallery. If you would be so kind as to send me the URI for it (or add me to it, whichever you prefer), that would be great. I'm not publishing to it yet, but I wanted to wire up the readme badges and nuget config, etc.

[dmccaffery]

@sayedihashimi I assume we don't want to use the .NET Foundation strong name key that came through with the fork/clone -- does OmniSharp have a SNK that we should be using instead?

[sayedihashimi]

Correct. Not sure if there is another key we can use. Maybe @davidfowl knows?

[dmccaffery]

I removed SN signing for now until we get feedback regarding that. Last question I have is around the license; do we keep the Apache 2.0 license used by the .NET Foundation, or switch to an MIT license used by OmniSharp? (based on my research) -- I'm not 100% sure what the implications are since we're currently utilizing source from the Scaffolding project in .NET Foundation.

Sorry to have so many questions. :sob:

[sayedihashimi]

Let's use the same license as OmniSharp for now.

[dmccaffery]

Done. PR is submitted. The packages are publishing to my MyGet feed at the moment (for testing), so someone needs to go in and update the feed URI and APIKEY environment variables in the AppVeyor configuration. I gave all scaffolding admins permissions to the project in appveyor, so anyone can do it.

Travis CI AppVeyor MyGet

The AppVeyor build is the one responsible for pushing packages, currently. The Travis CI is just doing a verification build (on Linux). I should probably add an OS X build to it at some point as well, but that's not really important until the unit tests start to get written.

Let me know if there is anything else we need at the moment.

[dmccaffery]

I noticed that KoreBuild emits some nefarious things in its logging -- doesn't seem to be built with public ally facing build/deployment scenarios in mind. It also lacks a coherent semantic versioning strategy for public builds, relying on variables emitted by TeamCity for versioning management, which we don't have in our infrastructure.

I'm going to update the PR to use Condo instead of KoreBuild, which has takes these needs into account. It's a minimal change, only effecting the build.cmd and build.sh scripts. We can revert back to KoreBuild very easily if any other issues are discovered, but I think it's the quickest way to get where we need to be.

Any other feedback on the PR from anyone?

[Muchiachio]

I can't comment on any of the CI stuff, because I'm living happily without them :smiley: Other than that, I don't quite understand our future vision here, there are all the sources? We will not be changing them? What are we going to do? :confused:

[david-driscoll]

@dmccaffery added you to the feed https://www.myget.org/feed/Details/omnisharp

[david-driscoll]

+1 on adding a Mac build

If there are any executables (scripts or otherwise) that need to run on Mac/Linux it probably makes more sense to publish to myget from Travis because we will need to chmod those scripts.

[dmccaffery]

@david-driscoll thanks; I'll get the OS X build up and running. There shouldn't be any scripts required; the package will be installed via "dnu commands install", which I don't think has any dependencies on shell scripts. If there are, I will switch the push to the travis build (its easy to do).

@Muchiachio Right now, the only source still included in this scaffolding package (once my PR is accepted), is the CodeGeneration project which was renamed to OmniSharp.Scaffolding. The next steps, as far as I see it, is to evaluate this command line "bootstrapper" to see if it will fit our needs. We'll be relying on the existing Scaffolding infrastructure to actually do the code generation -- all we're doing is writing a new CLI wrapper around it.

I haven't taken a look at the existing CLI yet -- just wanted to get a CI build system going and give us a starting platform from which to launch our efforts.

I'm currently performing my day-job activities, but will get the OS X build and Condo integration done tonight and we can move forward with evaluating the existing CLI tomorrow. If you want to take a look at the source from my PR, clone the repo and switch to the 1-nextsteps branch.

[sayedihashimi]

The next steps, as far as I see it, is to evaluate this command line "bootstrapper" to see if it will fit our needs.

Agreed

We'll be relying on the existing Scaffolding infrastructure to actually do the code generation -- all we're doing is writing a new CLI wrapper around it.

Also after we are in a good place with the command line experience we can also consider working around scenarios that VS scaffolding doesn't support yet. For example VS doesn't modify project.json and it doesn't modify startup.cs to register the dbcontext. So in that case we could do those required edits first and then invoke the scaffolding components. Later we can just pass it through.

The command line entry point in CodeGeneration (and possibly the whole project) will likely go away from the asp.net repo as cli support was recently cut and will be looked later on.

[david-driscoll]

@dmccaffery once you land the condo changes and stuff, let me know I'll review it as soon as I have time.

[dmccaffery]

Will do; my day job has crushed me the last few days, but I promise to get it done today. :)

[david-driscoll]

oh, no rush! I was just saying I'll check in when you can get it done. :smile:

[dmccaffery]

@david-driscoll Finally got around to switching the build system to condo, and the PR: #2 is ready for review.

[robbert229]

I was in the lync meeting today and am wanting to get involved with this project. What do you guys need done?

[dmccaffery]

Awesome! Right now I'm waiting on a review from @david-driscoll for the PR #2, but if you want to get started, we're just looking to evaluate the existing CLI prototype that was written by MS to determine if it will serve our needs.

My vision for this moving forward is to wrap all of the VS scaffolding capabilities with CMD line arguments, so it's possible to scaffold everything with one liners (which will allow visual studio to easily integrate with this at some point in the future).

Once that work is done, I would love to implement listing capabilities, where the CLI can list out available contexts, as well as available EF models. From there, introducing a wizard-like menu system similar to yeoman, whereby the user can be prompted to select the type of scaffolding requested, which model object to use, etc, to make it extremely easy to use.

The last step (in my mind) is to enable an extensibility story, whereby custom templates can be automatically discovered and surfaced by the CLI, both as an argument, as well as to be dynamically injected into the menu system.

To get started, we'll need to decide whether we want to use the existing CLI, or to roll out own from scratch.

You can pull down PR #2, or the 1-nextsteps branch, and play around until the PR is merged; from theirs, we should probably start writing unit tests and integration tests for all of our scenarios to prove out the existing CLIs capabilities.

A listing of what scenarios we want to support would be helpful.

[sayedihashimi]

@dmccaffery sounds like a great plan!

[david-driscoll]

So your saying I should review the pr? I'll put it on my todos for today when I have a small opening. :)

On Wed, Dec 2, 2015 at 7:32 PM Sayed Ibrahim Hashimi < notifications@github.com> wrote:

@dmccaffery https://github.com/dmccaffery sounds like a great plan!

— Reply to this email directly or view it on GitHub https://github.com/OmniSharp/omnisharp-scaffolding/issues/1#issuecomment-161476829 .

Thanks, David

[dmccaffery]

@david-driscoll : only because you asked to have an opportunity to do so 7 days ago. :-D.

[peterblazejewicz]

FYI: The scaffolding/templating topic was discussed during last ASP.NET live standup: https://youtu.be/CJeWIWkhVow?list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&t=1224

[Muchiachio]

Hello everyone, what are the plans for this repo moving forward? Maybe it's no longer needed or moved somewhere else? Last time I heard, we stopped to wait on RC2 release ~

[sayedihashimi]

Lets discuss in our next monthly meeting.

[dmccaffery]

I don't know either; I would still like to get this done, but I'm not sure what the starting point should be -- dotnet new vs dotnet waffle vs this, etc.

[dmccaffery]

Should we get together in separate meeting and lay out what we want with concrete next steps on how to get there?

[dmccaffery]

Hello? I've got some spare time opening up in my schedule and would love to get on this train if we're still going to do this. I do want to have a conversation around it with @sayedihashimi and @Muchiachio so that we go into a reasonable direction. I looked at the OmniSharp issues and didn't see an upcoming meeting -- looks like June didn't happen either, so I'm not sure where this is going. :)

[Muchiachio]

Yep, June meeting "missed" June for some reason :smile: