Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial checkin of some samples and a readme #1

Merged
merged 2 commits into from
Apr 7, 2014
Merged

Conversation

glennc
Copy link
Contributor

@glennc glennc commented Mar 28, 2014

We should discuss what goes in these samples. I put these in as a straw man to get some discussion and show the type of thing I thought should go in here.

We will probably add the KRuntime package to the repo, but I didn't want to fill this with the list of KRuntime files. So I will do that after we've agreed on something.


The samples provided are designed to show some of the features of the new framework as well as setting up a sandbox for you to try out new drops of functionality as they come out. The NuGet.config file in the repo points to a private MyGet feed that has all the packages being developed. The feed is updated every time a full build succeeds.

**The K.cmd file in the root of this repo is designed to be able to be put in your path. It will probe various locations relative to your current directory to find the KRuntime that it should" use. All the examples after this will assume you've done this, so that you can just type K Run from anywhere. If you choose not to then add the appropriate number of folder traversals (..\\) before each K command.**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extraneous " in the middle of this line.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terminology is mixed: are these 'examples' or 'samples'?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do regular Markdown files support the back-tick for "code" stuff? If so, do k run instead of K Run to make it clear it's a programmatic (i.e. command line) thing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed the extra " just after I sent the pull request. I've fixed it on my machine.

By examples I mean the instructions in the rest of the readme, not the samples. I'll make this clearer.

Yes, the markdown supports back-tick code. I'll change them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK thanks for clarifying the terminology - wasn't sure if it was deliberate.

@Eilon
Copy link
Member

Eilon commented Mar 29, 2014

Really not sure about checking in the package - that's likely even worse than re-downloading it again because each time we update it someone cloning the repo will download every version of the package.

@davidfowl
Copy link
Member

@Eilon I'm iffy on this. If things were more usable I wouldn't suggest checking it in but making people download ~20 megs per build is little nuts (only because the feed is so slow). An Alternative might be some kind of custom caching solution, but that will likely have bugs.

If you think re-downloading is ok then maybe we just do it and tell people we know it's slow but tough 😄

@Eilon
Copy link
Member

Eilon commented Mar 29, 2014

Yeah I don't think re-downloading is a good solution at all, but I'm not sure that checking the file in solves that problem once we've got a few builds in the history (now you have to download 3 * 20MB = 60MB) just to get one 20MB build. Can we tell people to stash a copy in some magically-named folder and we pre-configure something in their special copy of k.cmd to know about their stash? Basically an extra local NuGet feed?

@glennc
Copy link
Contributor Author

glennc commented Mar 29, 2014

Downloading it once and leaving it in the packages folder achieves the same thing as some sort of special cache doesn't it? IIRC our intent is to set the samples to use a LKG set of pinned packages anyway, so they are will not be updating it every build.

As a data point, I timed restoring all packages for the samples several times on my machine. It could take anywhere from 1-10 minutes with the KRuntime already in the packages directory. It seemed to average around 2 minutes. I didn't try it also restoring the KRuntime but when I was installing it on its own it usually took 20-30 seconds I think.

@Eilon
Copy link
Member

Eilon commented Mar 29, 2014

If we only ever release one KRuntime to Insiders I don't care either way. But the moment we have two or three snapshots or KRuntime then cloning the repo will be disastrous because it's all cumulative (unless perhaps we go rewrite history or something).

@Eilon
Copy link
Member

Eilon commented Apr 7, 2014

:shipit:

@glennc glennc merged commit 206f745 into master Apr 7, 2014
glennc pushed a commit that referenced this pull request Jul 24, 2015
Avoid full rebuild every time.
04050564 pushed a commit to 04050564/Home that referenced this pull request Dec 11, 2017
natemcmaster pushed a commit that referenced this pull request Oct 17, 2018
jkotalik pushed a commit that referenced this pull request Nov 1, 2018
natemcmaster pushed a commit that referenced this pull request Nov 9, 2018
ryanbrandenburg pushed a commit that referenced this pull request Nov 16, 2018
Everything but the kitchen async... (Updates to how Music Store controllers use data)
    
Specifically:
    - Dispose contexts
    - Use async wherever possible
    - Stop using initializers (currently hard-coded to drop and recreate each run)
    - Some general cleanup
    - Stop using AttachDbFilename
    
Not included here:
    - No major changes to app structure
    - No major changes to data model
    - No major changes to error handling, concurrency, etc.
ryanbrandenburg pushed a commit that referenced this pull request Nov 19, 2018
Add Microsoft.AspNetCore.Hosting.Azure.AppServices package
natemcmaster pushed a commit that referenced this pull request Nov 20, 2018
Update with recent changes from aspnet/Hosting
ryanbrandenburg pushed a commit that referenced this pull request Nov 22, 2018
Updated logging extension to remove the period on ValidationFailed
natemcmaster pushed a commit that referenced this pull request Dec 1, 2018
- Remove constructor defaults
- Make service properties internal
- Add Logging/HttpContextAccessor services which are required by
identity
@SSpormann SSpormann mentioned this pull request May 30, 2022
1 task
mkArtakMSFT pushed a commit that referenced this pull request Feb 24, 2023
…controller) (#46714)

* add dotnet new templates (razor view, api controller, mvc controller) (#1)

* added razor view

* fix identity for razor view item template

* added api controller

* fixed api, added mvc controller

* pr comment fixes

* PR comment fixes 2

* fixing postActions.description

* changed encoding for razor view Index.cshtml
Jesusdebug pushed a commit to Jesusdebug/aspnetcore that referenced this pull request May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants