You don't need to tell them how to structure their projects. Instead, make it a hard requirement that you can build the system from source by running one single script, without getting any errors. If that scripts runs Visual Studio or Msbuild or some other tools, and if those are called once, 50 or 100 times should not matter.
That way, you get the same "...
Roslyn also appears to have the ability to "script" code and compile/execute it on the fly (similar to the CodeDom) but I have only come across limited uses for that type of functionality in my experience.
On-the-fly compilation and execution is the key benefit of Roslyn. I think you may be undervaluing the benefit of this feature because you have never ...
It looks like size of your client is important.
From Visual Studio 2013 and MSDN Licensing Whitepaper - November-2014 page 10:
"Example 2: A Fortune 500 firm has outsourced the development of its store-locator mobile application to a small agency. The application is not an open source project. The agency has 5 employees working on the project and would ...
The biggest difference is that Express editions do not support plugins (No ReSharper, no add-ons). Additionally, the non-express versions are all combined, meaning you don't have to switch back and forth to get features from individual express versions if you have a project that crosses web, desktop, etc.
UPDATE 8/6/2015 - If you're looking for a free ...
There would have been a simple way which had kept your new development separate from the main branch without bringing you into this unfortunate situation: any change from the trunk should have been merged into your dev branch on a daily basis. (Was your client really so shortsighted that he could not anticipate that your branch needs to be remerged back ...
TL;DR: no, Microsoft are not discouraging the use of 'var' in C#. The image is simply lacking context to explain why it's complaining.
If you install VS2017 RC and open up the Options panel and go to Text Editor -> C#, you'll see a new section: Code Style. This is similar to what ReSharper has offered for a while: a set of configurable rules for coding ...
Yes - I can think of two primary benefits:
Beyond its primary functional purpose (i.e. to reduce code verbosity), the 'Using' statement list at the top of a code file can tell future readers (especially those without Resharper) which namespaces are (or at least were) relevant to that code file. If you actively prune this list, it can act as a better ...
You can do time-consuming things like writing a wrapper around the external API that leaves out your undesired operations, but nothing beats training and code reviews, because whatever standards or technical measures you put in place, people will find creative ways to get around them.
For example, we have several services written in Scala, and one of the ...
It looks like you've fallen into some of the common pitfalls, but don't worry, they can be fixed :)
First you need to look at your application a little differently and start breaking it down into chunks. We can split the chunks in two directions. First we can separate controlling logic (The business rules, data access code, user rights code,all that sort of ...
It doesn't have to be in its own file, but your team should decide on a standard and stick to it.
Also, you're right that "Go to definition" takes you to the interface, but if you have Resharper installed, it's only one click to open a list of derived classes/interfaces from that interface, so it's not a big deal. That's why I keep the interface in a ...
There aren't any performance benefits, if that's what you mean.
All references in an assembly are fully qualified; the compiler merely uses the references you provide in your code to fully qualify identifiers, so the only impact of unused references in your source code is a slight decrease in readability (why is this reference here?), and a trivial ...
There are several methodologies that have evolved over the years to deal with these issues you've mentioned, which are, I agree, the two main issues that UI frameworks have had to address in recent years. Coming from a WPF background, these are approached as follows:
Declarative design, rather than imperative
When you describe painstakingly writing code to ...
Recently, we migrated nearly all the source code in my company into a single solution.
Originally, we had dozens of solutions. Some projects from a solution reused projects from another one, and nobody cared about using a package manager. The day you substantially change a project which is used nearly everywhere, expect hours and hours of lost work ...
Visual C#, like Visual C++, is simply Microsoft's implementation of the C# language, along with the IDE and design-time tools used for developing C#. The terms are usually interchangeable, since in Windows land, for many years, Visual Studio was almost the only development tool, and is still the most dominant one. So, when learning Visual C#, anything you ...
On MSDN, there are some very old official guidelines. These are out of date though. As the page says, "This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies." So I'd recommend you avoid these guidelines.
There was an attempt to define a common solution structure via ...
First point of fact is that the solution file pretty much magically becomes a MSBuild file when MSBuild executes it -- which is what happens when you build the solution in visual studio. In addition, all those project files are just msbuild files managed by visual studio. In fact, the project files handle most of the real dirty work here no matter if you are ...
I am using this
Updates your title to for example:
Hope it helps
Short answer: Your link is good, but you are looking in the wrong place.
A good reference to compare Express with Standard is Comparing Visual Studio and Visual Studio Express 2012 for Web edition.
In general, the Express edition is lacking all design tools that you may need for architecture.
In prior VS Express versions, there was also lack of the NuGet ...
The makefile for msbuild is the .sln file (or vcproj file).
A typical msbuild command line would be something like:
msbuild /p:Configuration=Release BigProject.sln
The point of using msbuild is so you can script and automate the build process. Whether you were aware of it or not, TeamCity has been using msbuild all along.
I guess the "correct" way to do this is to have a protected constructor on the base class which requires the state name as a parameter.
public abstract class State
private readonly string _name;
protected State(string name)
throw new ArgumentException("Must not be empty", "name");
This is a great question! Much programming advice and "best practices" comes down to the question of managing complexity. Or to put it plainly: How do we write and manage a large complex program without being overwhelmed. The solution is (like with most large problems) to split it into smaller, more manageable pieces.
Each variable is a bit of complexity, ...
I think you should keep them separate files. As you said, the idea is to remain testable and interchangeable. By placing the interface in the same file as your implementation, you are associating the interface with the specific implementation. Should you decide to create a mock object or another implementation, the interface will not be logically separate ...
At that stage of merge I would say that automated merging may only over complicate the process. I have had similar issues with branches that have diverged for over a year and the most effective method I have is to do the following:
Take a copy of the original unmerged state
Diff between the unmerged and latest
Break down any common elements
For example, do ...
I won't use VS2010 without it (see disclaimer). That and productivity power tools. I use both in VS2012 too. I think it improves the development experience significantly. I can navigate the code quicker, refactor way quicker.
It can be a resource hog, but the functionality helps me a lot.
*disclaimer: I did actually use 2010 recently for about three ...
You have two options.
Create separate mywebsite.api and a mywebsite.app projects in your solution.
Proper separation of concerns.
You can deploy updates to your api and your front end independently.
Architecture of sites can be changed independently (i.e. you can update your api to run on asp.net 5 without affecting the website)
Your unit tests are in a separate project and serve a separate function from your main code, so putting them into a separate namespace makes the most sense to me.
If you're considering putting them into the same namespace just to save the using line, then don't. Less code is good, clearer code is better.
I'm sure companies which provide tooling (e.g., JetBrains*) are very interested in Roslyn. Microsoft wants to make it easy to make tooling, because good tooling encourages the use of Microsoft's ecosystem.
*Per the JetBrains blog (this entry), JetBrians has announced that they will not be using Roslyn. However, I imagine that any new competitors to ...
In one comment you say most of your customers are using XP.
You make the false assumption that it's good for your company to drop XP support.
You come with technical reasons but the only good reason you can give to your manager to drop XP support is:
"It's going to make us more money."
That's the only reason there is. And honestly I don't think you have a ...
C# is a programming language.
Visual C# is Microsoft's implementation of the language. Microsoft uses the “Visual” prefix as a brand name for programming-related products, e.g. “Visual Basic .NET” or “Visual Studio”.
There are a number of other C# implementations as well, most importantly Mono. While both Mono and Visual C# implement the same language, ...