File name convention for C# v10 global using declarations - naming-conventions

Is there a consensus within the C# development community on the .cs filename in which global using statements are declared?
I was going to adopt the filename GlobalUsings.cs but then found that a hidden file called MyProject.GlobalUsings.g.cs is created behind the scenes by the VS2022 toolchain. This is to support the related new C# 10 feature called Implicit global using directives.
Blazor has supported a similar feature for .razor files and the Blazor solution template automatically creates a file called _Imports.razor. That name is derived from the Razor syntax to declare a using reference.

Short Answer
Usings.cs or maybe GlobalUsings.cs.
More Info
There are actually 2 new features. They seem really simple at first, but the more you read about it, the more complicated it becomes.
Global using directives. You can use global in front of any using directive in any file to make it global in the project.
Implicit usings. This automatically adds a set of common global using directives depending on the project type. You can enable this in a project that is upgraded to .NET 6 buy putting this in the project csproj file: <PropertyGroup><ImplicitUsings>enable</ImplicitUsings>...
Implicit usings is enabled by default on new .NET 6 projects, so it sounds like the convention is:
Use implicit usings.
You may still need a file to store global usings that are not implicit. I like your idea of GlobalUsings.cs. It's self-documenting.
In fact, this naming is recommended by the Welcome to C# 10 Blog. I highly recommend reading it; it was really helpful to me.
EDIT:
This seems to keep changing. .NET 6 project templates are now including a Usings.cs file.

Related

Customizing msbuild for .NET Core with something like CustomBeforeMicrosoftCommonTargets

For a long time, I have been very successful at non-invasively customizing many .NET Framework builds by setting CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets as environment variables in a command-line shell that corresponds to a given development/build workspace.
I would set these environment variables to point to custom msbuild targets files that would then be automatically imported (before and after respectively) the import of the standard Microsoft provided targets files. This has worked great for a long time, but now .NET Core comes along and I find no mechanism quite like that.
I am aware of Directory.Build.props and that does not appear to be equivalent. For one, it is invasive requiring me to add a file to a source tree that I don't want to necessarily touch in order to customize its build (maybe its an open source project and I don't want to be injecting new files into it). For two, it doesn't provide the dual Before/After import hooks which are very important (if this duality weren't important Microsoft would never have provided it).
I also don't like dropping magic files in magic global locations as my build policies/customizations are themselves versioned source code which can vary from one developer workspace to another (even on the very same machine for the very same developer).
It seems odd that Microsoft would fail to retain such a long-standing and fundamentally useful msbuild customization capability in .NET Core. Am I missing an equivalently powerful, easy to use and non-invasive mechanism? Is it there and I just haven't found it?
CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets are still part of MSBuild 15 which is included in VS 2017 and the .NET Core SDK.
Setting them as global variables will still import them and override the default locations used if not set. Use the /bl argument to generate a binary build log and the MSBuild structured log viewer to diagnose issues you may have with it.

Is it possible to use live-templates as file templates?

In the intellij products I'm very fond of the live-templates. I wonder if it is possible to use the same syntax for file templates, e.g. formatting a variable to snake- or camel-camese, defining a starting cursor position and so on.
Unfortunately you cannot use the same functions/macros available in Live Templates in File Templates.
File Templates use Apache Velocity template language. It allows some Java(?) simple methods to be run on variables (e.g. #set($class_start = $class.substring(0,1).toUpperCase())). Quite possible that more complex methods will work as well.
UPDATE (2017/01/13):
As of 2016.1 (or perhaps 2016.2) version it's now possible to use some Live Templates in File Templates as well (by checking Enable Live Templates checkbox for that File template). I'm not 100% sure if it will do the requested here thing (not tested myself).
Syntax example: #[[ $MY_VARIABLE$ $END$ ]]#
https://www.jetbrains.com/help/phpstorm/2016.3/file-and-code-templates-2.html

What DLL file do I need to add to my solution to use DbSet?

I am trying to use the generic DbSet class. I have tried adding the following references so far to my solution because the MSDN documentation states that DbSet lives inside System.Data.Entity:
However, as shown below I still cannot add a reference to System.Data.Entity, the only suggestion intellisense has is EntityClient which does not contain DbSet:
Resharper/Intellisense is not giving me any other suggestions of namespaces I could possibly add.
I have tried cleaning and rebuilding my solution, and I am using the .Net Framework 4 full version (not the client version).
I have tried using NuGet to search for EntityFramework and have found one result which I have added to no avail as is show below:
What DLL file do I need to add to my solution to add a reference to System.Data.Entity and use the DbSet class?
Thanks
The same MSDN reference page that you mention says that you need to reference EntityFramework.dll in your project.
Note that namespaces and assemblies are not the same thing. The following statement is a little over-simplified, but you can think of namespaces as residing inside (or becoming available by referencing) an assembly.
So, once you've referenced the assembly, you will still need the using System.Data.Entity; directive.

Hide 3party empty namespaces

When I add an 3party Library (Gibraltar.Agent) to a VB.NET project I get namespaces which interfere with my current code.
For example the namespace Gibraltar.Agent.IS makes the following code invalid:
Assert.That("bla", [Is].EqualTo("bla"))
as a solution i have to fully qualify [Is]
Assert.That("bla", Nunity.Frameworks.Is.EqualTo("bla"))
Also annoying is the "I" namespace, which makes the following invalid:
For i = 0 to 10 'valid without referencing Gibraltar.Agent
For i as Integer = 0 to 10 'needed change after adding Gibraltar.Agent
How can i hide the unwanted 3Party namespaces?
EDIT
I did not add any Gibraltar namespaces.
The following does not help either:
Imports [Is] = NUnit.Framework.Is
You could create a new Class Library and create wrappers around the Gibraltar.Agent functionality you use, then just reference this class library instead of Gibraltar.Agent from your other projects.
See also the Adapter pattern.
These odd namespaces are created by an obfuscation library used by an older version of VistaDB which is ILMerged into the Gibraltar Agent. The obfuscator substitutes two-character symbols for VistaDB namespaces to conserve space.
We acquired VistaDB last year and now have a free hand to rework its internal structure and build process. This issue with namespaces leaking through will be resolved in Gibraltar 3.0.
Jay Cincotta
Founder
Gibraltar Software
Just don’t Import that namespace in your files. You may need to change the project settings if you have at some time in the past activated that namespace for inclusion in your project settings.
But according to the documentation the objectionable names don’t even exist.

Create a custom file extension in VB 2008

I have been doing a lot of searching on the web and cant seem to find a clear way of creating a custom file extension. I know to associate the file extension to a certain program, but how do create a format for the custom file extension?
You can do that as well through setup application as described in Walkthrough: Deploying a Windows-based Application, and you can pick any extension you like. I prefer to use abbreviation created from application name, and try to find if this extension is not in use. If extension was in use, then old reference (link between file type and application) will be broken. Use of 4 characters extensions will help with better chance of extension to be unique.