We Keep Coding

Anything wrong with putting connection strings in applicationSettings? [duplicate]

This question already has answers here:
Pros and cons of AppSettings vs applicationSettings (.NET app.config / Web.config)
(6 answers)
Closed 7 years ago.
.NET has supported a number of ways to store configuration settings for quite some time, which has led to a good deal of confusion. It doesn't help that the top three hits for a search for "Settings in C#" over on MSDN are ten years old (and many of the related questions [2] on this venerable site are also 6-7 years old). It is really hard to determine which of the early recommendations have since been deprecated.
In my project I have chosen to use ApplicationSettings (as opposed to AppSettings) because:
That appears to be the current recommended approach on MSDN (and here).
The AppSettings element appears to be deprecated as of .NET 4+* (topic is "no longer available"; but see "Other Versions" on that page.) [*Although, confusingly, the AppSettings Property is still supported]
I prefer to edit the settings in a designer tool, rather than an xml editor.
I prefer strongly typed settings.
However, now I need to decide where to put my connection strings. The most current documentation on MSDN (and here on SO, as well as CP) still appears to recommend using the <connectionStrings> section of the app.config. But accessing this from the code requires the use of the old syntax, which I now consider obsolete along with appSettings. In other words, it makes no sense to read one part of the app.config file with the old syntax:
ConfigurationManager.ConnectionStrings["MydDBConnName"];
and another part of the same file with the new syntax:
Properties.Settings.Default.myOtherSetting;
Plus, it prevents me from being able to edit the strings in the designer.
So bottom line: is there any reason not to standardize all my configuration settings (including the connection strings) in the ApplicationSettings element?

The ConnectionStrings section allows you to not only define the connection string in the config, but also lets you choose the provider, so you code can (theoretically) use any subclass of DbConnection, DbCommand, etc.
In reality, however, supporting that kind of flexibility means you have to use SQL statements that are provider-agnostic (meaning you can't do things like date math that do not have a standard SQL syntax), and require more "plumbing" code to create the right types of objects. You can see some examples here.
If you only support one database provider (SQL Server, Oracle, ODBC, OleDB) then there's no real benefit to using ConnectionStrings over a string application setting.

I suggest that you keep your classes settings-source agnostic.
For example if you have a DatabaseContext that requires a connection string, then inject that primitive dependency in the constructor. Do not locate the connection string directly via ApplicationSettings.
Locating primitive dependencies (e.g. settings) from your classes is exactly the same as using the Service Locator anti-pattern.
The only location in your application that should acquire settings (e.g. connection strings) is the Composition Root. So you can obtain settings from ApplicationSettings here and inject them into your classes.
This allows you to change your mind later if you want to use a different way for storing/retrieving settings.

As you must have read on the pages that you linked to, the main benefit of using <connectionStrings> is that it provides mechanisms for encrypting the strings in order not to keep passwords in clear text. If you use Windows authentication to connect to the database then I guess you don't need it and really doesn't matter where you keep your connection strings. It's just a standard way of doing this.
I believe, however, that you are mistaken saying that the 'old syntax' is deprecated. For example, <appSettings> is still documented, it just changed the address. It would bring havoc if it was. It's not my area, but I think what you refer to as the 'new syntax' is the way of accessing settings in a desktop application, you don't have it in server-side applications.

I believe the ApplicationSettings element is just used for organization. If you notice in Entity Framework or most other database connections, they store them in the config under the ConnectionStrings element. The only thing I would worry about is storing any sort of sensitive data such as connection user and password. A common way to get around that is to allow the Windows Authentication to handle the connection.

A standard is what you make. For example in my current work environment the only information that changes in a particular application is the server name. We have dev/test/prod servers. Therefore we only store the SQL Server name in the configuration file. The database name doesn't change. We just read the database server from the configuration file and build the string in the application.

Naming conventions in c# [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Not sure if this follows the rules or not, but I need some help with names. How should I approach project name vs namespace vs class. For example, I want to make a datacleaner program. So I name it Datacleaner, and then DC for the class, and then Cleaner.cs for the file name, and it just gets all confusing. Is there some best practice I can be following here!? A helpful mindset or naming theory would be exceptionally helpful.

It is slightly off-topic, but I'll give you a shot here.
The first thing we need to look at, is the root namespace. Depending on what you're doing, this root-namespace may be shared across multiple projects. A good example of this is System. You might put your company name there, or you might choose something more eclectic. If I am writing library code, I avoid things like DataCleaner because libraries are supposed to be generic and don't pertain to a common form.
So, you're writing a data cleaner. Great! There's nothing wrong with having a common library and having a Data namespace (maybe you want to add more things pertaining to data in the future), and then you have your Cleaner class.
If I were a user of your API, I'd happily understand that <library>.Data was a namespace and I need to be looking for Cleaner.

Microsoft has an excellent set of guidelines - See the next link:
Guidelines for Names
Also see the Naming section
I think you'll find there all the info you need.
This question already asked in StackOverflow, see here

You should Mike Roberts' series on How to Set Up A .Net Development Tree. It's a bit dated, but the concepts still hold true. Links to his articles are in my answer here: https://stackoverflow.com/a/9982500/467473 (he seems to have rearranged his blog and broken the links therein, though the content is still there). Also see Tree Surgeon, a tool for creating solutions using the principles Mike Roberts espoused.
In a nutshell, lay out your source tree thusly:
Fundamentally, your directory structure should look like this:
Meta/Development RootUsually mapped to root of source control system.
SolutionOne directory, contain your entire solution. Should be named to match the solution.
Solution.slnThe solution file itself.
nant.buildThe nAnt build file for the solution.
libThe lib directory contains 3rd party assemblies/dlls that are referenced by the different projects in your solution. It is under source control. Project references should point here.
toolsThe tools directory contains all 3rd party tools required to build your solution. It, too, is under source control. The tools directory should contain the versions of nAnt, nUnit etc. used by your project — and your build scripts should reference these, rather than the version(s) installed on a developer's machine.
binThe bin directory contains the output of the build process for the solution. Each projects must be configured to point here.
debugdebug build
releaserelease build
objIn the ideal world, each project's obj would be pointed here as well as this has no place in the source tree. Sadly, Visual Studio doesn't offer an official way to do that (though, I'm told, VS can be hacked to do so if you're resourceful enough).
srcThe src directory is the root directory for the actual source code of your solution.
project1The directory for project1.
project.csproj`The project file.
*.cs, etc. files. The source files.
...
project-n
The src directory contains the actual source code. Each project should be named with its full namespace. Whether you lay them out flat or build out the whole namespace structure in the file system is up to you. The idea is that the namespace should guide you to the source file.

Here is a short summary of conventions from another SO question:
Naming Convention in c#

The other answers here are all spot on, for C# you probably want to follow the naming conventions put forth by Microsoft (and are automatically used by default if you are developing with Visual Studio) unless you have a compelling reason not to.
Project Namespace should match the Project Name or should match the Project Name with some standardized prefix prepended.
Conventions for class and files are 1 class per file and the file name should match the class name.
You are forbidden to name give a class the same name as it's namespace, which I assume is the issue you ran into that prompted this question. The solution to that is probably to give the project a more general name.
To give a more concrete example of what we do where I work.
Any product we produce here we typically have a solution with two or more projects in it.
The default namespace for any project follows: ...
If the DataCleaner product had a windows service and a command line tool that dealt with the same domain you might have three projects: Console, Service, and Domain with name spaces of
Company.Team.DataCleaner.Console
Company.Team.DataCleaner.Service
Company.Team.DataCleaner.Domain
For naming of classes (and by extension the files they reside in), if you follow the above scheme you already somewhat get around the problem of having a DataCleaner class in your DataCleaner namespace, but you may find application of the Single Responsibility Principle useful. To put it simply, any class should only do one thing. If you have a class named Cleaner or DataCleaner they might be trying to do too much, and breaking it up would result in names specific to the resulting classes

Examples of user-writeable config files?

Looming on my (C# 4.0) project horizon is the introduction of a user-configuration feature, wherein my colleagues need to obtain the ability to configure our software or a pre-run basis so that it will perform its duties in whatever way is needed. Every run (they'll tend to be lengthy simulations) will have have its own configuration file.
In the main, they'll want to define "products", fairly complex beasts comprising run-time parameters, IOC-style information (lists of calculation classes required in a Strategy Pattern-like way) and more stuff besides. Values could be numbers (integer and floating-point), strings, dates and lists of these.
We know the content will change (new parameter names, for example) as new products are introduced or existing ones evolve.
Options I've looked at include, in descending order of (my estimate of) syntax-heaviness:
XML
YAML
JSON
a DomainSpecific Language?
Some app-specific text notation
I'm looking for examples of more-or-less similar things: file formats, discussions of pros and cons from a technical and/or user perspective.
(I expect that at some time in the future we'll consider introducing a graphic front-end for such exercises, but we'll need to be able to configure executions some time before then.)
EDIT/UPDATE: I'm not particularly concerned about ease of implementation from the technical perspective: I'm looking for something my (very smart, but not technically-oriented) users will best be able to use to minimize the difficulty of writing what may be a fairly complex configuration.
Maybe "configuration" is a bad choice of word - what if we called it "simulation definition file" and considered that each user will create many of these over time?

If all of this can be described in a regular, attribute oriented way, it sounds like XML would meet your needs. C# has fantastic XML handling features including built-in serializers and LINQ that can save a ton of code implementation time. Also, creating a forms based UI from a schema is very straight forward.
I would suggest sitting down and creating a pseudo-schema to see if this would handle your use cases to help decide if this approach would work for you.
For examples, take a look at one of the many plugin systems that are driven by XML. The first one I would recommend is Eclipse.

In C# easiest way is to use a Built In Class System.Configuration ,first you should add an Configuration File ,using Visual Studio ,than you can edit it's attributes . Here is a How To

C# Interpreter (without compilation) [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there a ready-to-use C# interpreter out there, that is does not rely on runtime compilation?
My requirements are :
A scripting engine
Must Handle C# syntax
Must work on medium-trust environments
Must not use runtime compilation (CodeDomProvider ...)
Open source (or at least free of charge both for personal and professional use)
If this is not clear, I need something like Jint (http://jint.codeplex.com/), but which allows me to write C# scripts instead of JavaScript ones.
Thanks for your help.

Have you looked at paxScript.NET?

Check out the Mono project. They recently demoed CsharpRepl which sounds like what you're after. The PDC 2008 video here.
Update:
On a close look it seems like using Mono.CSharp service to evaluate scripts won't be possible. Currently it is linked to the Mono runtime and they don't expect it to run in a medium trust environment. See this discussion for more info.
On alternative possibility is to include the Mono C# compiler (sources here) in your project and use it to generate assemblies that you load from the file system. It you are worried about the resources required to load all those assemblies you might have to load them in a separate AppDomain.

I need to evaluate 10000+ small
scripts that are all differents,
compiling all of them would be just
dramatically slow
Interpretting these would be even more painfully slow. We have a similar issue that we address as follows:
We use the Gold Parser project to parse source code and convert it to an XML based 'generic language'. We run this through a transform that generates VB.Net source code (simply because it's case insensitive). We then compile these using the .Net runtime into a standalone DLL, and call this using heavily restricted access.
It sounds as though you are creating something like a dynamic website where people can create custom modules or snippets of functionality, but using C# to do this introduces a couple of main problems; C# has to be compiled, and the only way around this is to interpet it at runtime, and this is unfeasible, and even if you do compile each snippet then you end up with 10,000 DLLs, which is impractical and unusable.
If your snippets are rarely changing, then I would consider programatically wrapping them into a single set of source, with each having a unique name, then compile them in a single shot (or as a timed process every 10mins?). This is what we do, as it also allows 'versioning' of peoples sessions so they continue using the version of DLL they had at the start of their session, but when every session stops using an old version then it's removed.
If your snippets change regularly throughout the day then I would suggest you look at an interpretted scripting language instead, even PHP, and mix your languages depending on the functionality you require. Products such as CScript and LinqPad all use the CodeDomProvider, because you have to have IMSL somewhere if you want to program compiled logic.
The only other option is to write your own interpretter and use reflection to access all the other libraries you need to access, but this is extremely complex and horrible.
As your requirements are effectively unachievable, I would suggest you take a step back and figure out a way of removing one or more restrictions. Whether you find a FullTrust environment to compile your snippets in, remove the need for full code support (i.e. move to interpretted code snippet support), or even change the whole framework to something non .Net.

LINQPad can work as a code snippet IDE. The application is very small and lightweight. It is free (as in beer) but not open-source. Autocompletion costs extra but not much ($19).
Edit: after reading over the comments in this post a little more carefully, I don't think LINQPad is what you want. You need something that can programmatically evaluate thousands of little scripts dynamically, right? I did this at work using Iron Ruby very easily. If you're willing to use a DLR language, this would probably be more feasible. I also did some similar work with some code that could evaluate a C# lambda expression passed in as a string but that was extremely limited.

I have written an open source project, Dynamic Expresso, that can convert text expression written using a C# syntax into delegates (or expression tree). Expressions are parsed and transformed into Expression Trees without using compilation or reflection.
You can write something like:
var interpreter = new Interpreter();
var result = interpreter.Eval("8 / 2 + 2");
or
var interpreter = new Interpreter()
.SetVariable("service", new ServiceExample());
string expression = "x > 4 ? service.SomeMethod() : service.AnotherMethod()";
Lambda parsedExpression = interpreter.Parse(expression,
new Parameter("x", typeof(int)));
parsedExpression.Invoke(5);
My work is based on Scott Gu article http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx .

or http://www.csscript.net/
Oleg was writing a good intro at code project

It doesn't handle exact C# syntax, but PowerShell is so well enmeshed with the .NET framework and is such a mature product, I think you would be unwise to ignore it as at least a possible solution. Most server products being put out by Microsoft are now supporting PowerShell for their scripting interface including Microsoft Exchange and Microsoft SQL Server.

I believe Mono has mint, an interpreter they use before implementing the JIT for a given platform. While the docs in the official site (e.g. Runtime) say it's just an intermediate state before consolidating the jitting VM, I'm pretty sure it was there the last time I compiled it on Linux. I can't quite check it right now, unfortunately, but maybe it's in the direction you want.

bungee# is the thing that you want, in a short time, bungee sharp will be an open source project in
http://www.crssoft.com/Services/Bungee
. you can create scripts with the same c# syntaxt. there is no assembly creation when you run the script, interpretation is done on the fly, so the performance is high. all the keywords are available like c#. I hope u will like it very much..

I faced the same problem. In one project I was looking to provide a generic way to specify conditions controlling when a certain letter has to be generated. In another project the conditions were controlling how cases were assigned to queues. In both of them The following solution worked perfectly:
The Language for the snippets - I chose JScript so that I do not have to worry about variable types.
The Compilation - yes it requires full trust, but you can place your code in a separate assembly and give it full trust. Do not forget to mark it with AllowPartiallyTrustedCaller attribute.
Number of code snippets - I treated every snippet as a method, not a class. This way multiple methods can be combined into a single assembly
Disk usage - I did all compilation in memory without saving the assembly to disk. It also helps if you need to reload it.
All of this works in production without any problems
Edit
Just to clarify 'snippet' - The conditions I am talking about are just boolean expressions. I programatically add additional text to turn it to methods and methods to compilable classes.
Also I can do the same with C# although I still think JScript is better for code snippets
And BTW my code is open source feel free to browse. Just keep in mind there is a lot of code there unrelated to this discussion. Let me know if you need help to locate the pieces concerning the topic

This one works really well
c# repl and interactive interpreter

Is Snippet Compiler something you looking for?

Convention for Filenames of Generic Classes [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I want to be able to distinguish between a generic and regular (non-generic) version of a class. Much like the .NET framework does with it's generic and non-generic versions of several of it's interfaces and collection classes. (Queue, Queue(T))
I generally like to follow the convention of one class per file (as in Java). Is there a common convention for naming files containing a single generic class? I'm mostly interested in Windows (NTFS specifically) but it seems like a good convention would be (at least a little) portable.

At Microsoft, they use ClassNameOfT.cs.

Just found this question after looking for what conventions other people use for generic class filenames.
Lately I've been using ClassName[T].cs. I really like this convention, and I think it's superior to the others for the following reasons:
The type parameters jump out at you a
little more than they do with the
Microsoft convention (e.g.,
ClassNameOfT.cs).
It allows you to have multiple
type parameters without too much
confusion: Dictionary[TKey,
TValue].cs
It doesn't require you to create any special folders, or to have your generic classes in a special namespace. If you only have a few generic classes, having a special namespace dedicated to them just isn't practical.
I borrowed this convention from Boo's generic syntax, albeit slightly modified (Boo uses ClassName[of T]).
Some developers seem to have a phobia of filenames that contain anything but letters and underscores, but once you can get past that this convention seems to work extremely well.

I see that this topic has been abandoned more than a year ago, but still I would like to share my view on this convention.
First of all, having multiple classes that have the same name but only differ in the amount of type-parameters isn't always a case of backwards compatibility. Surely, you don't see it very often, but the new Action- and Func-classes of .NET were just designed this way, and I'm currently implementing something similar.
For clarity and distinguishability, I use the following convention that only specifies the number of generic arguments for a given type:
MyClass.cs
MyClass.T1.cs
MyClass.T2.cs
This way, my filenames stay short and simple while still clearly communicating the class-name and the different amount of type parameters at the cost of a simple extra dot (which is, in my experience, a commonly accepted thing to do in a filename and looks much better than comma's and other non-alpanumeric characters, but this is just a matter of taste I guess). Putting the names (or acronyms) of the type parameters just lengthens the filenames while at this level I'm not really interested in the actual names of the type parameters anyway...

Don't use the grave accent ` in your generic file names if you're running Visual Studio 2008. There's a known issue with them that causes breakpoints to fail:
http://connect.microsoft.com/VisualStudio/feedback/details/343042/grave-accent-in-filename-causes-failure-to-recognize-target-language-breakpoints-fail

Personally I wouldn't use the grave accent notation:
Foo.cs
Foo`1.cs
For the simple reason that I am scared of the grave accent. Not only does it have a scary name 👻😨😱, but I am unsure how it will be handled by different file systems, version control systems and in URLs. Hence, I would prefer to stick to common alphanumeric characters.
NameOfT.cs seems to be used in ASP.NET Core according to a search on GitHub. 40 results. Reference.
Also used in the .NET Core runtime. 36 results. Reference.
Example:
Foo.cs
FooOfT.cs

Sometimes I also see ClassName{T}.cs but it is common to name it ClassNameOfT.cs (like mentioned before Microsoft uses it)
EntityFrameworkCore project(also Microsoft's) uses ClassName`.cs

All new Microsoft classes use generics. The Queue and ArrayList were there before generics came out. Generics is the way forward.
The convention for one-class-per-single file is to name the filename after the class name (whether generic of not). For MyClass, you'll have MyClas.cs. For every new namespace you'll need to create a new folder. This is how Visual Studio also works.

How about:
Type.cs
and
TypeGeneric.cs
Whenever I have done this in the past I have always put both types in one file with the non-generic type as the file name. I think that this makes things pretty clear as .NET has no conventions/restrictions on one type per file like Java does.
But if you must then I would suggest something like I have above, and using a suffix will make the files show up together in any alphabetized list (Solution Explorer, Windows Explorer, etc.).
Here is another idea:
Type`1.cs
This would allow you to break out different generic types by the number of generic type parameters they accepted. Its just a thought though as I still think it would be simpler to just put all the types in one file.

I would probably put them in folders and use the namespace mechanism instead. You can compare with System.Collections vs. System.Collections.Generic. On the other hand, if it's more common than not that the classes use generics, perhaps it's better to point out those that are not. That is if you really want to separate the generic classes from other classes. Personally I usually don't bother to do that, since I don't really see a practical benefit from it.

From the responses so far it seems there isn't a consensus.
Using the same filename in a sub-namespace (and sub-folder) "Generics" (like System.Collecctions.Generics) is an option. But it's not always desirable to create a new namespace.
For example, in an existing namespace with non-generic classes that are maintained for backwards compatibility, but marked with ObsoleteAttribute, it's probably better to keep the generic versions in the same namespace.
I think a suffix is a reasonable way to go. I've adopted a convention of using the type parameters as a suffix (so: MyClassT for MyClass<T>, or MyDictionaryKV for MyDictionary<K,V>.

I'd probably have two folders in the project, something like Gereric, NonGeneric or something like that. They can still be in the same namespace, and then they can both have the same file name. Just a thought...