I use Visual Studio 2010 for C# development. But, there are many times during the day when I need to quickly try out a small bit of C# code to experiment or learn something new. I can write this as a fully functional C# program in a single file. Now, I can use Visual Studio for writing/editing this C# files, but it does not support execution or debugging (breakpoint, watch variables) unless I create a solution for it.
I would like to have the ability to create, edit, execute (and hopefully debug) single C# files, without having to go through the pains of creating a VS solution everytime I need to try something. Is there a simple C# IDE on Windows in which I can do this?
The IDE should not create any project/solution files. That way I can have a directory of C# files, each of which is a full C# program and each of which I can open to read, edit and execute with this IDE anytime I want.
LinqPad can execute expressions, statements, or small programs that could be a single file in size (also see this page). It does not create projects/solution files just as you are seeking. Just open, code, and save if you like. I use the free version to test code I post on this site.
It supports .Net 4.0 and has some other nice features, such as not needing to explicitly specify using statements. The program is smart enough to know which ones you need.
Try Snippet Compiler
In the next release of C# and Visual Studio, one of the new features is Project Roslyn, a compiler-as-a-service implementation. The upshot is that this enables is scripting in C#, with .csx files. The Visual Studio blog has a lot more information on .csx files here.
I myself haven't played with .csx files much, but they seem similar to .fsx files for scripting F#, in that you take the code that you would normally place inside a method (in F#, a function) and place it at top-level, and can use the hash to introduce compiler directives (e.g. #r to reference a DLL).
Related
the book I'm reading went briefly over command line building, specifically controlling the linker.
But any class and .cs file containing classes or resources seems to link just fine if they reside inside my project, can I just ignore the command line builder for now until I'm more profficient in C# or is this something I need to know right now?
CommandLine builder using csc.exe in my knowledge is not used by even experienced professionals. Everyone goes the route of Visual Studio latest versions and it is safe to ignore commandline building.
But you can try and understand how it works. Because, in the end this is the one which is used by your GUI tools like Visual Studio to do the build.
I would generally say it is worth knowing how to use the command line building, but it is not a necessity. I started off just using Visual Studio and wasn't even aware of command line building for C#. However, since I learned to use it and write Command Script files to execute it, I actually use it fairly often - especially when working on large projects that have multiple dependencies in need of building. In that situation, it saves opening multiple Visual Studio instances.
Agreed with Muthu. Building via CSC.exe is good option and works for simple setups or for learning, but if you have a complex solution structure in Visual Studio using inter-project dependencies, post build events, etc. its best to just invoke the Visual Studio build call itself via the command line. The command is devenv.exe and you'll find lots of documentation on it.
If you are trying to learn C# complier/linker innards maybe you'll be more interested in Project Roslyn from Microsoft as they try to open the "black box" of the compiler.
I am currently working on a project which supports multi-language. I have created a resource file (.resx) that contains all the strings that the application uses. The main resource file is embedded into the application (an .exe), and the translations into other languages will be compiled into satellite assemblies. The way I use those strings in my application is by calling:
Resources.ResourceManager.GetString("MyResourceKey");
Now my question is, is there a way to find out if there are strings in the main resource file that are not used by the application? The reason I want to do that is that during development there might be messages that were added there, and then we changed our mind and stopped using the message without removing it from the .resx file. Now we need the translation for the other languages and I'd like to ask the translator only for the messages that are really used.
I've seen that it might be possible to do that with code analysis but my version of visual studio doesn't include code analysis. Are there some free third party tools or some code I could easily write to find that out?
Thanks to all
There is a Delay.FxCop code analysis rule to find unused resources. I haven't used it, but it may be just what you're looking for.
I'm beginning to work on a COBOL/BASIC IDE at work (to replace the one that we have currently that's a slight step up from Notepad). It'll be made in C#. The management is really interested in implementing some Visual Studio type features, and a big one is code folding. I've looked on MSDN, but I didn't see any good way to collapse lines (or to add the expand/collapse buttons).
I'm assuming that the text area should be a RichTextBox. Am I off track here? I suppose it could be done with some sort of modified TreeView, but that seems a little wrong to me. Is there some way of doing this that I'm just missing?
Why not use an existing IDE and extend it? Writing one from scratch is a huge undertaking (you need a parser, lexer, syntax highlighter and more), and is even more complicated if you need to support multiple languages (you mention COBOL and Basic).
Notepad++ has syntax coloring and one can add languages to it - COBOL is one of the ones installed by default. It supports code folding and has many plugins (you can write your own, that will suit your needs).
Edit:
Eclipse is another excellent IDE that has similar support, and as mentioned in the comments has a COBOL plug-in.
I suggest you take a look at SharpDevelop. It's a pretty good IDE with a bunch of Visual Studio like features already built in. It's written in C# and fully supports code folding with syntax highlighting in several languages. Plus, it's Open Source under the LGPL license. So, if you don't want to base your app on SharpDevelop then you can still reuse some of their controls like the code editor or windowing toolkit.
You should consider adding the COBOL language to SharpDevelop instead of starting from scratch. If you can't do this, then you can still use the SharpDevelop code as a decent reference on how to make a good IDE work.
Sometimes embedding Eclipse or a full-fledged editor is not appropriate. It's overkill or overweight or wrong for some other reason. I appreciate the first inclination suggested in other posts to not re-invent here, but in some cases a small invention is what is necessary. For example, the textbox used to make Stack Overflow posts .... is neither Eclipse nor an embedded Visual Studio. I wonder why?
It's important to ask the question - build it or buy it? - but sometimes, the correct answer is BUILD IT.
XPathVisualizer provides a simple example of a code-folding text editor implemented in C#, and based on a RichTextBox. It's not VB, though - it's an XML editor. But the general principles apply.
Here's a look at it.
To implement XML syntax colorization dynamically, while the user types, it uses a separate background thread. The reasons why and some of the details are described in a separate answer on Stack Overflow.
You could do something similar for your COBOL/VB thing. XPathVisualizer is open source, licensed with MS-PL, so you can browse and borrow.
If your team is used to "Visual Studio features," then I'll assume you use Visual Studio there at the office. Here are my suggestions:
Base your IDE on Visual Studio, for the following reasons:
Use Visual Studio 2010 if possible. The SDK is greatly improved from 2008/earlier.
Use Visual Studio 2008/2005 otherwise. At the moment, all of my commercial IDE products only support 2005/2008.
If your team uses Visual Studio, they will hate Eclipse. Not even an option to consider in this case unless you choose to use an existing Eclipse plug-in, saving you the time of creating a new IDE.
If your team isn't using Visual Studio 2010, you can use the Visual Studio 2010 Shell in Integrated Mode for free (Isolated Mode is not what you want). This lets you use Visual Studio 2010 for your IDE for now, and should the team upgrade later to one of the full versions of Visual Studio 2010, the IDE for your language will cleanly integrate into the full version. Edit: Visual Studio Shell is basically the core of Visual Studio without any specific languages (C#, C++, VB, etc.) included. Microsoft provides this core for free, and it's a great option specifically for people interested in creating their own language support.
Read my answers in the following two questions:
Here's a longer post on my reasons for using 2010 over 2008: How do I implement intellisense support for a custom DLR language in VS2008?
Here's a very long answer on implementing various features (most of which are based on the 2005/2008 SDK): How do i implement intellisense for my language in visual studio?
Writing a complete IDE is a HUGE task. I would recommend trying to find an existing one that has what you want, or make adaptions to an existing open source IDE.
To answer your question: I guess that the Visual Studio IDE uses a custom control, written from scratch, rather than a RichText control.
My knowledge is very limited on VS in fact it's the first time I am using it and very little I know of C debugging too.
I have pre-existing .c and .o files that have been transferred into my folder and I open VS to edit them. I then compile on a unix windows with the icl command. What I get is obviously error messages because those files have been run in Linux compilers and never into Windows ones.
In blogs I always find mention to changing project properties when it's about resolving, i.e. _CRT_SECURE_NO_DEPRECATE warnings or other types of errors. My problem is that I don't see those .c files as projects when I open them from VS so I cannot change those properties.
Do I have to turn them into projects? Or do I have to simply move them into folder where VS opens files from by default?
Help is needed, please.
Thanks
F
You cannot use .c file in a C# project, it is a completely different language. Forums cannot really provide you with a short-cut for basic knowledge and skills you'll need to acquire to bring this project to a good end. You'll need to take the time, experiment, read a few books.
This is a quess. This assumes that your code is not dependent on anything.
You should create a C project (you may have to use empty project)
Add your c files to the project.
Right click solution and hit build.
How can I convert my C# code to DLL file in a way that the user of DLL can’t view my source code?
When I make DLL in the way I always do by making a class library project, importing my classes and compiling it, the source code can still be viewed.
I believe you are looking for an obfuscator. This is a tool that will take a compiled DLL and rewrite the code with the intent of it not being meaningfully decompiled by another user. Visual Studio comes with a free Dotfuscator
Note, this will not actually prevent people from looking at your code. They will instead be looking at a very weird translation of your code. There is no way to prevent people from looking at decompiled versions of your code in C# or any other .Net language for that matter.
This is not something that is unique to C#. It is fact a flaw of every language in existence. It's perfectly possible to decompile C code. The difference though is it's much easier to maintain a lot of the original code structure when decompiling managed languages (.Net and Java for instance) because the metadata maintains the original structure.
obfuscation is what you want to search for.
There is a free one (that is limited) in visual studio called Dotfuscator.
Uses fancy methods to rename your code and alter flowpaths to obscure it.
Consider using an obfuscator.
If you are developing desktop applications converting your code to Dll will not hide the it( there are many tools to decompile the dll or exe files).
but if you are using Asp.Net, then you can compile your site to Dll, and the code will not be visible in the aspx pages, it will be compiled to Dll, you can do that by right click on your project on solution explorer, then choose Publish website
But in all cases .Net Exe files and DLL will be easy to decompile and extract the source code again, unless you use tool to obfuscator your code.
If you mean, the end-user can view your source code by decompiling it, you can protect yourself using an obfuscator.
There is standard obfuscator build in into Visual Studio. In the menu choose Tools / Dotfuscator community edition.
I think my reply to a similar question about JavaScript obfuscation applies here as well: in short, why bother? Your question has already been answered here ("use an obfuscator"), but I thought it wouldn't hurt to find out what your motivations are. Generally, code that you give to people is "in the hands of the enemy" -- if somebody wants to use it/figure out how it works badly enough, they will.