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

C# Console App template doesn't use namespace for Program class, but adding classes will have a namespace #271

Closed
dsplaisted opened this issue Oct 13, 2016 · 2 comments
Assignees
Milestone

Comments

@dsplaisted
Copy link
Member

dsplaisted commented Oct 13, 2016

The .NET Core Console application template doesn't use a namespace in Program.cs. That is simpler and cleaner, but if you add a class to the project from Visual Studio, the new class will be inside the default namespace for the project. This means you'll have to add a using statement to Program.cs to use any additional classes.

Possible fixes I can think of:

  • Do nothing, let people rely on quick fixes to add the using statement if they need it
  • Add using $safeprojectname$; to the Program.cs template
  • Update the Program.cs template to put the Program class inside the default namespace for the project
  • Get rid of default namespace for console apps in the SDK altogether. This would probably mean a condition in the targets that only sets the default namespace for class libraries (or some similar criteria). The new class template in VS (and maybe all code templates) would need to be updated so that it doesn't try to put the class in a namespace if the default namespace is empty.
@davidfowl
Copy link
Member

Why isn't this fixed yet? There should be a namespace.

@davkean
Copy link
Member

davkean commented Dec 16, 2016

It wasn't fixed because you never submitted a PR. :)

The namespace was removed just to simplify the Hello World, we can add it back.

dsplaisted added a commit to dsplaisted/sdk that referenced this issue Jan 26, 2017
GangWang01 pushed a commit to GangWang01/sdk that referenced this issue Jun 27, 2022
* Tags become choices, lots of help changes

* Rebased on rel/sv2017/post-rtw

* Post-Rebase cleanup of outputs for various situations. Moved tags to symbols on 2.0 templates

* Reverted to tags in 1.x templates and Item templates

* Removed extra space from tags secifications in 1.x templates

* Reverted to tags in 2.0 templates

* Fixed misspelling of 'language' in 2.0 template.json files

* Changes based on review comments (not including case-insensitive reads yet)

* Rebased on rel/vs2017/post-rtw

* Made reading template config & cache info be case-insensitive.

* Made cache parameter properties get only

* Cleanup of help & ItemplateInfo

* Minor cleanup, mostly removing no longer needed async tasks

* More cleanup

* Tags become choices, lots of help changes

* Rebased on rel/sv2017/post-rtw

* Post-Rebase cleanup of outputs for various situations. Moved tags to symbols on 2.0 templates

* Reverted to tags in 1.x templates and Item templates

* Removed extra space from tags secifications in 1.x templates

* Reverted to tags in 2.0 templates

* Fixed misspelling of 'language' in 2.0 template.json files

* Cleaning up UI interactions. Better experience for: problems with extra args files (dotnet#327, dotnet#329); default not in choice list dotnet#271

* Added support for split template configuration files (dotnet#150)

* Cleanup of nulls in the template cache

* fixed a merge mistake

* More fixes from merge issues

* Make fallback host files work correctly

* Added wildcard to host matched. Fixed a bug with wildcard matching in zips

* Add filter switch, hide all switch, add logic for accepting explicitly set filters

* Change filter to type

* Give instructions to call --help instead of showing help on error

* Remove unused using

* Fixes dotnet#380 and dotnet#379

* Respond to review feedback

* Make the message shown for the invalid params match between help and non-help cases

* Set IsPackable=false for new test projects (dotnet/templating#376).

The rationale for this is that creating NuGet packages from tests is probably not the more-common use case and so by default these project should not participate when "dotnet pack" is run at the solution level.

This doesn't prevent users from opting into "dotnet pack", it simply won't be the default.

* Make IsPackable configurable for test project template (dotnet/templating#377).

* Use '-p' as the short form for '--enable-pack' in MSTest v1 project template.

* Implement "--enable-pack" parameter for test project templates (dotnet/templating#377).

This parameter, if set to "true", marks the project as packable (i.e. participates in solution-level calls to "dotnet pack", producing a NuGet package).

* Build for non-Windows platforms

Refactor to use latest cli

Add RestoreSource for dotnet-new3 project

Build with framework version and runtime id

Fix test cases

* Move testbase location to local directory

* Updating the identity of the 2.0 templates

* Better matching across templates with same group identity.

* Added precedence to all template.json files

* Reading & writing template Precedence

* Template matching uses Precedence to help disambiguate templates

* fix for dotnet#395

* Updated package refs in test projects

* fix for exclude, include, & copy only configuration in sources

* Mikes test harness for testing dotnet new commands. Tests for precedence disambiguation

* Fixes per Mike's CR

* renamed the mvc precendence tests

* Add 3PN for nuget.exe

* Allow runtime to be passed in

* Handling reading different cache formats, and upgrading the cache aut… (dotnet#407)

* Handling reading different cache formats, and upgrading the cache automatically as needed

* Cleanup for cache versioning

* Improvements to cache versioning. Language display fix.

* Cache rebuild enhancement. Only scan mount points for templates and langpacks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants