{"id":29285890,"url":"https://github.com/lordmilko/simplevuetemplate","last_synced_at":"2026-04-15T22:35:34.355Z","repository":{"id":75540894,"uuid":"491819292","full_name":"lordmilko/SimpleVueTemplate","owner":"lordmilko","description":"Simple template for creating an ASP.NET Core (.NET 5) API + Vue 3.0 project","archived":false,"fork":false,"pushed_at":"2022-05-20T13:07:14.000Z","size":209,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-07-05T23:13:19.151Z","etag":null,"topics":["asp-net-core","net5","net50","visual-studio","vue","vuejs","vuejs3"],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lordmilko.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2022-05-13T08:31:53.000Z","updated_at":"2022-05-13T14:03:12.000Z","dependencies_parsed_at":"2023-03-11T19:58:48.476Z","dependency_job_id":null,"html_url":"https://github.com/lordmilko/SimpleVueTemplate","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/lordmilko/SimpleVueTemplate","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lordmilko%2FSimpleVueTemplate","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lordmilko%2FSimpleVueTemplate/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lordmilko%2FSimpleVueTemplate/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lordmilko%2FSimpleVueTemplate/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lordmilko","download_url":"https://codeload.github.com/lordmilko/SimpleVueTemplate/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lordmilko%2FSimpleVueTemplate/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31863495,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-15T15:24:51.572Z","status":"ssl_error","status_checked_at":"2026-04-15T15:24:39.138Z","response_time":63,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["asp-net-core","net5","net50","visual-studio","vue","vuejs","vuejs3"],"created_at":"2025-07-05T23:12:41.167Z","updated_at":"2026-04-15T22:35:34.343Z","avatar_url":"https://github.com/lordmilko.png","language":"C#","funding_links":[],"categories":[],"sub_categories":[],"readme":"# SimpleVueTemplate\n\n[![Appveyor status](https://ci.appveyor.com/api/projects/status/8psqq59hww01ipla?svg=true)](https://ci.appveyor.com/project/lordmilko/simplevuetemplate)\n\nThis repo provides a Visual Studio 2019 template for creating a simple, *fast* Vue website with an ASP.NET Core API backend.\n\nGetting to the point where you can create such a project is far from straightforward. There is a plethora of outdated information out there on setting up such a project; even\nthe instructions you're following to seem to work, you may find the F5 debug experience to be painfully slow. Anything less than near instantaneous debugging is completely unacceptable. This project is the result of my research.\n\nAfter creating a new project from this template, you will have a ready to use, quick to debug .NET 5.0/Vue 3 website\n\n## What's in the box?\n\n* ASP.NET Core Empty project targeting .NET 5.0, without HTTPS\n* `vue create clientapp --no-git` using the Vue 3 template and the folder renamed to ClientApp\n* `Startup.cs` configured to use controllers and your Vue SPA App\n* Lightweight, fast, ASP.NET Core Vue Middleware capable of using Hot Reload across debugger restarts\n* `*.csproj` configured with minimal dependencies and the standard Vue/npm MSBuild targets\n\n## Options\n\n* If you want to use a Vue project with different options (e.g. you want to use TypeScript), simply delete the entire `ClientApp` folder and do `vue create clientapp` in your project (not solution) directory (I changed the capitalization of this folder so it looks nice, but you don't have to)\n* As described below, Hot Reload does not work across debugger restarts when reading from the `npm` server's console (which is what all other Vue ASP.NET Core Middleware solutions do). As such, by default `SimpleVueTemplate` simply polls to\nsee when the `npm` web server has come up. If you are experiencing issues with your web server however and want to see what's going on, kill `node` if it's already running and then change your launch target from *IIS Express* to *YourProjectName* and specify `VueServeMode.Parse` to `UseVueDevelopmentServer()` in `Startup.cs`\n* If you attempt to debug this project in Visual Studio Code, setting `VueServeMode.Poll` will cause `npm run serve` to run in the integrated terminal window, thereby causing Hot Reload issues if you close and reopen Visual Studio Code. To work around this,\n  either run `npm run serve` manually before debugging, or if you are on Windows you may specify `VueServeMode.Isolated` to `UseVueDevelopmentServer`, which will cause a brand new window to open (minimised) containing the running node server.\n\n## Observations\n\n### ASP.NET Core\n\n* [VueCliMiddleware](https://github.com/EEParker/aspnetcore-vueclimiddleware) seems like it'd be the way to go, however it seems to be way slower than [this](https://www.c-sharpcorner.com/article/getting-started-with-vue-js-and-net-core-32/)\n* Webpack similarly slows the F5 process down.\n* `UseProxyToSpaDevelopmentServer` has a 2000ms delay if you try and connect to `localhost` since it actually tries IPv6 first; therefore you need to specify `127.0.0.1` to force IPv4 (VueCliMiddleware added this as well in 2020, however older VSIX's on the marketplace such as [this](https://marketplace.visualstudio.com/items?itemName=alexandredotnet.netcorevuejs) are still using VueCliMiddleware 3.0 hence are affected by this issue)\n* The way Vue ASP.NET Core Middleware typically works is that you connect to the stdin/out/err of `npm run serve` to detect when the backend server has properly started. However, if you\n    * Stop the Visual Studio debugger (after having already started it)\n    * Start the Visual Studio debugger again (thereby reattaching to the existing `npm run serve` that is still running)\n    * And then modify a `*.vue` file\n  You will find that Hot Reload no longer appears to work. If you then refresh your webpage, node.js will in fact terminate itself, requiring the ASP.NET Core Proxy to recreate the server! While I don't know exactly why this happens (it isn't crashing), it's definitely got something to do with the fact our middleware attached itself to the input/output streams of the npm server. As I haven't been able to find an easy way around this, my solution is to provide the option to simply not connect to the server's input/output streams at all\n* [You may want to consider enabling the Script Debugger](https://www.reddit.com/r/dotnet/comments/unzi8b/psa_the_more_windows_you_have_open_the_longer_it/) to make Visual Studio launch your web browser faster. You may find that the Script Debugger causes its own annoyances...but in any case this this is something to be aware of if you keep a lot of open windows\n\n### VSIX Development\n\n* The Visual Studio Project Template you export from existing code can't simply be incorporated into a VSIX; is it because a `TemplateID` is not specified?\n* Files in your project template won't be extracted unless you specify `\u003cCreateInPlace\u003etrue\u003c/CreateInPlace\u003e` in the vstemplate\n* Microsoft really wants you to strongly name the assembly containing your `IWizard`. If you don't want to do that though, you need to ensure that the assembly you specify in your `*.vstemplate` `\u003cWizardExtension\u003e` matches the assembly\n  specified in the corresponding `\u003cAsset\u003e` of `source.extension.vsixmanifest`. By default the manifest contains `\u003cAsset AssemblyName=|%CurrentProject%;AssemblyName|\"/\u003e`which expands to the strong name of your assembly. [Microsoft hasn't documented)[https://github.com/MicrosoftDocs/visualstudio-docs/issues/820]\n  what possible macros can be specified in manifests, however with a quick bit of reverse engineering we can see that targets defined in `Microsoft.VsSDK.targets` can be specified, and `VSIXNameProjectOutputGroup` gives us our project name without a file extension. Alternatively, you can just hardcode your assembly name in the manifest\n* .NET project types have a fancy second screen in Visual Studio 2019 where you can enter in values such as the .NET Framework version, whether to use HTTPS, etc. Based on this you may think it's possible to create fancy integrated wizards rather than having to design\n  your own `IWizard` interface, however this is not the case. It is possible for .NET Core templates packaged up in a VSIX to show additional options on the main window, however these options are only used to perform simple substitutions within your source text; you can't do something more\n  complex like run an arbitrary program to provide a list of possible options for a dropdown list.\n  \n  Why is it not possible to design your own fancy integrated wizard like the one .NET projects do?\n  * Templates are instantiated via an `ITemplateProvider`. The two main template providers used in Visual Studio 2019 are `LegacyProjectTemplateProvider` (from `Microsoft.VisualStudio.Dialogs.dll`) and `NetTemplateProvider` (from `Microsoft.VisualStudio.TemplateEngine.VS.dll`)\n  * In order for a `Template` to display a secondary configuration page within the normal new project screen, `HasInputDescriptor` must be true. This is never the case for templates created from the `LegacyVsTemplateProvider`\n  * Secondly, the `ITemplateProvider.GetTemplateInputDescriptorAsync` must return a `TemplateInputsDescriptor` containing a list of `ControlDescription` objects obtained from an `ITemplateParameterProvider`. This interface is not public hence it is not possible to add your own control descriptors\n  * In that case then, is it possible to trick Visual Studio into reading your template via the `NetTemplateProvider` instead of `LegacyProjectTemplateProvider`? `NetTemplateDialogFilter` (from `Microsoft.VisualStudio.TemplateEngine.VS.dll`) declares all well known template types. If you're not in the list, you don't get to display additional input fields\n  * [The only possible out](https://github.com/dotnet/templating/issues/1987) for you is if you do [declare](https://github.com/ligershark/sidewafflev2/blob/master/templates/SideWaffle.Template/.template.config/sidewaffle.vstemplate) a wizard in your vstemplate, but point to `Microsoft.VisualStudio.TemplateEngine.Wizard.TemplateEngineWizard` instead of an actual template a `none` `$uistyle$` and either a `$templateid$` or `$groupid$`. The only issue here is that Visual Studio will lookup whatever `$templateid$` or `$groupid$` you specify\n    against a list of known IDs that comes from somewhere. Your extension didn't declare either of those two properly (and in fact I think you need a `.template.config\\template.json` .NET Core template file to do so), so your superhack fails. sidewafflev2 does seem to know how to declare its group properly somehow\n  * But even if you did manage to trick Visual Studio into allowing custom inputs for your project, it's still completely pointless, because all known input controls are provided via a series of predefined `ITemplateParameterProvider` types, which magically come from somewhere via MEF. You would need to do some crazy\n    dynamic programming to create an instance of a type derived from `ITemplateParameterProvider`, and even then you have to deal with a whole bunch of MEF stuff. No thanks","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flordmilko%2Fsimplevuetemplate","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flordmilko%2Fsimplevuetemplate","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flordmilko%2Fsimplevuetemplate/lists"}