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 3 years ago.
Improve this question
I have about 4-5 years of background in programming some in C# and some in C++. I recently got an internship and have been using C# daily. I am confident in my work, and don't have any problem remembering syntax or anything like that. So I was wondering what you think about getting resharper? I was going to demo it first but I just want to hear other opinions about it. Basically what I'm trying to ask is, should I wait to get it and become more experienced and have more practice with just Visual studios and its built in intellisense and stuff or would it be alright to get it?
I wouldn't work without it. It duplicates a bunch of the Visual Studio stuff, and adds a whole lot more. It simply improves Visual Studio, and will not impair your learning c# at all.
I'm a developer that has been using C# since .net 1.0 days on a daily basis, I usually likes to keep to the bare bones of an installation, so that if my dev environment is somehow destroyed I can be back and running as fast as possible. However, I recently did some pairing with another developer which required installing Resharper. What I found was:
I learnt alot about C# features I never new existed.
It had a much better test runner than VS.
Had much better refactoring tools.
About the only thing I didn't like was that it rearranged some of the default VS keyboard shortcuts, however after a bit of tinkering in the options dialog I was able to turn off the features I didn't need.
I'm missing it now, after the trial. I'm unfortunately unable to afford the cost of a licence (cash flow problem, not a it isn't worth it problem) at present and can't convince my bosses to get it for me.
Make a point of trying out Refactor Pro and CodeRush during your research as an alternative to Resharper. Together they're an unstoppable productivity machine. I used them for years when I developed in C# and working without them feels like I'm missing an extra me. :-)
For sure you should look into both products, though. It's not about remembering syntax, it's about reducing the number of coding errors that everyone makes all the time.
I can tell you from my experience that no matters how solid are your skills ReSharper is quite addictive, and it's a great enhancement for C# programming in VS. In fact the addiction comes from the fact that it can really make you save a lot of time otherwise spent doing tedious tasks and at the same time it'll help you write clean code which turns in less time spent refactoring (which is made faster by ReSharper anyway).
If properly configured, it can be - in my opinion - the most valuable VS addin and I couldn't really see why you should deny yourself access to that :)
Well worth the money, particularly if you can get your company to buy it for you. I theoretically could work without it, but I wouldn't want to.
Resharper is like learning piano chords and then being able to play any song you hear. You can write code the "wrong" way, highlight some of it, do a key combination, and clean it up.
v4.5 makes huge strides in performance as well. Some big solutions would get bogged down, but this one is a lot snappier. It's solid top to bottom.
Related
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 5 years ago.
Improve this question
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI
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 5 years ago.
Improve this question
I love programming languages and trying to think of logical solutions to problems. A lot I have been reading on C# and the underworkings of WPF. (Also Python and PyQt) In all my college courses in programming, I learn absolutely nothing (What a variable is, what an array is, NOT what stack and heap are, NOT what CLR/JVM actually does) I feel I have a very good grasp on the basics and a decent grasp on the more substantial topics.
I have been trying to make my own C#/WPF app that is governed by input sensors and output relays for home/shop automation.
I am having trouble to just do certain things. For example. make a user control to be used by a central control that also controls another user control while having a database layer.
I would really like to learn how to structure logically programs and what best design is (for example, I hate having a program filled with if/else statements). The problem is, the books I find only have basic examples that don't really deepen my overall undestanding of how all the pieces need to work together.
How do I start to do things?
You find an open-source (or at least "source available at no cost" -- not quite the same thing, but the difference should only matter if you plan to redistribute your results) project that does "something like" (maybe "vaguely" like;-) what you're trying to do, and is coded in a language that you know or want to learn.
You duplicate the source tree for that project to your machine and put the duplicate under a version control system (svn, hg, git, bazaar -- whatever -- there's a bazillion good, free ones) quite independendently from any VCS it might have been in originally -- the point is being able to save your edits all the time, and revert them easily if and when you make mistakes.
Then you start hacking, looking things up in docs and forums, asking on SO, etc, as needed;-).
There is no "one shoe fits all" solution in programming world. But i do recommend you a book. Hope you like it.
Head First Design Patterns
(O'Reilly)
Honestly... truly... the best answer? Do stuff.
I learned a lot in school. Tons. But as you said, there is a level that schools don't touch. I've got a deeper understanding in my 2 months of programming/data analyst than I got in 2 years getting my AA in programming.
Realize one thing: School is there to teach you a wide range of things - to a minimum level. You won't become an expert from school alone (There are exceptions... as with any rule).
How have I actually started to understand stuff? Programming. Boss gave me a program task and I ran with it.
Personally, I've really liked Apress books. C# 2008 Illustrated (or the soon to be released 2010) has proved invaluable to me. I actually read 95% of the book, double checked examples... and most importantly... put them into practice in my horrible first programming task. I've re-factored at-least 5 times already, and already am seeing things that will make me do it again.
I don't know if you have a job... or a hobby... an open source program you'd like to help with... or a task you'd like to automate. Pick something, learn it inside out, then program it.
Personally, again... I'd say joining an already running open-source project is too much. I tried a few times and it was too much for me. To many things I didn't understand. I plan to try again once I get a little better, but I don't plan on hanging out on NBA courts when I can barely dribble the ball myself... if ya know what I mean.
How do I start to do things?
Find a problem that needs solving and writing a program to do it. It doesn't have to pretty or efficient. The program just needs to work. As you work with the program you'll begin to learn better techniques for accomplishing the task you set for yourself. Google and SO will be your friends and help you learn those better techniques.
As other have said, jumping straight into controlling hardware with C# may not be a simple task for your first program.
Good luck.
Read Martin Fowler's book Refactoring: Improving the Design of Existing Code.
Martin Fowler gives you the building blocks to think about high level design decisions by introducing you to all the low level decisions you may or may not be aware that you are making. He also gives a good introductions to the concept of code smells.
Look at design principles like DRY Do Not Repeat Yourself, KISS Keep It Simple Stupid, and keep it consistent(Pet Peeve).
More design principles here
Design Principles.
Practice these principles as often as possible especially in your course work and outside projects..
Get involved in open source
Hard to do but probably will help you the most especially when combined with the first two.
Personal Experience feel free to skip.
After three years of tough undergrad I realized I could solve some really complex proofs but I didn't know how to write anything but spaghetti code. The longest projects I had were 5 months long which was enough time for it really to catch up with me. I was usally very productive for the first 2-3 months but was crawling along from the code debt by month 4. At this point I had the same realization you did.
Everyone says the best way to learn was to practice but I didn't know how to practice.
I realized that the problem with thinking about design was I couldn't move one design into another. A professor mentioned Martin Fowler's book Refactoring: Improving the Design of Existing Code and that has made all the difference.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
We are looking for methods to improve our internal processes when developing software.
We have already adopted TDD contiguous integration and Agile. Any obscure features of visual studio or TFS?
All suggestions welcome.
I don't think there can be a magic bullet. Beauty (or in this case quality) is in the eye of the beholder.
With that said, I can give you some suggestions as to some of the ways we ensure code quality.
One suggestion can be to include Code Coverage into your assessment of Software Quality. It is one thing to have unittests written for your code, but code coverage helps you identify what code is actually 'covered' by a test, which can sometimes identify use-cases/scenarios that you may not have considered. I recommend you investigate nCover.
You may also wish to dig deeper and look into using nDepend...
NDepend is a tool that simplifies
managing a complex .NET code base.
Architects and developers can analyze
code structure, specify design rules,
plan massive refactoring, do effective
code reviews and master evolution by
comparing different versions of the
code.
I appreciate that these are not TFS features but you can easily 'integrate' them into your visual studio environment using TestDriven.NET
This is of course not an exhaustive list of things - you need to find what suits you and gives you the confidence about your code's quality.
Hope this helps,
Here's a helpful list: http://www.joelonsoftware.com/articles/fog0000000043.html ("The Joel Test: 12 Steps to Better Code" by Joel Spolsky)
If you really don't have anything to do, and you have the resources you can try code review. This procedure includes double checking the code before every (real) commit. This helps to catch bugs early in the development process. Google is using this technique widely.
Sadly the tools supporting these kind of procedures are pretty basic and hard to use currently. If you do a googling on you'll find one or two simple code review tool for TFS.
Be careful though. These techniques doesn't help you make good software alone. You still need a good architecture, quality code, etc. (Okay, TDD helps code quality, but architecture is still a gray area.) I'm not aware of any techniques that help that currently and doesn't hurt the development process too much. You have to wait till Visual Studio 2010 comes out with all the bling-bling of model validation, automatic uml diagram generation, etc.
Personally I believe in code reviews. Some of advantages are:
Constantly keeping an eye on code quality and coding standards.
It's easy to notice any unusual/buggy/hard to understand coding structures (i.e. long if conditions, strange type conversions, etc.).
While reading someone else code it's easier to notice all false assumptions (could be negative false) (i.e. this object is never null), which could introduce bugs.
It makes familiar with all changes to source code, so it's easy to remember that this piece of code was lastly modified (which could introduce bugs).
It makes easy to learn (and teach) good habits.
And I do not believe in any tools, which are thread as special kind of silver bullet -- which is not true.
read: Code Complete
It is good that you have implemented TDD, CI and Agile. Just having ANY process is far better than many places I have seen. Code reviews are probably the single best way to disseminate knowledge and flesh out defects early.
For my money, though, stick to the basics. If you are not doing requirements management, you should consider it. You should know what your customer requirements are when you start your sprint or development cycle. Conduct a review of those and discover your derived requirements, if any. Lastly, you should come up with a way to verify that 1) you built everything you intended 2) you tested everything the customer asked for. There are processes to do this but if you can find a way that's good for you, do it!
RM takes less time than code reviews and catches the "really big" mistakes.
You are probably the most happiest guys if you have already adopted TDD, CI and Agile and have nothing to do =) I think you have a very big field of process improvement with TDD and Agile practices.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We are planning to develop a client server application using C# and MySQL. We plan to sell the product on the shelf like any other software utility. We are worried about the decompilation of our product which does have some sort of edge over our competitors in terms of usability and bundled functionality.
How can we prevent our software from decompilation, so the business logic of the product remains intact?
We have heard about Reflector and other decompilers which makes our code very much vulnerable for copying.
Our customer base is not Corporates but medical practitioners who themselves may not do it but our competitors may want to copy/disable licensing or even replicate the code/functionality so the value of our product goes down in the market.
Any suggestion to prevent this is most welcome.
If you deploy .NET assemblies to your client machines, some kind of decompilation will always be possible using reflector and similar tools.
However, this situation isn't materially different to what you'd encounter if you wrote the application in native C++. It is always possible to decompile things - if it were impossible, the processor couldn't understand it either.
You're never going to defeat the expert cracker - they'll treat your security as an intellectual puzzle to be solved for the challenge alone.
The question revolves around how hard it is to defeat your licensing practices and the return on investment.
Sit down with a spreadsheet and look through the possible scenarios - the danger is probably less than you think.
Factors like "ease of use" are visible in your software for any user to observe - so you'd think it easy to copy. But, good User experience is rare (and seldom copied well), because most developers (myself included) are nothing like typical users.
I'd suggest you concentrate on making the job of a cracker harder, cause you can never make it impossible, just non-profitable.
One possibility to try: It's possible to pre-compile assemblies into native code as a part of the installation process. Paint.NET does this for performance reasons. I believe that once you've done this, you can discard the original assemblies and use the optimised, native code editions.
If it were me, I wouldn't be attempt to obfuscate; I would:
Not worry about it and aim to continually improve and stay in front
But secondly
Consider providing the 'secret' services over the Web. It's up to you to decide how critical and possible this is; but it does "prevent" decompilation, because the end user doesn't even have the code.
Google for .NET Obfuscator. You will find a lot of products that will help in this. Also there are related questions already asked in Stack Overflow.
Here are some:
Dotfuscator
Secure Team
EDIT: While searching for De-Obfuscating tools, I came across an open source tool De4Dot. This tool supports decompiling obfucated dlls created by most commercial tools and does a pretty good job too.
Intellilock has served our purpose well in terms of obfuscation as well as licensing. But I would not recommend the product as the support is not upto the mark. We never got replies in time for the problem we were facing. We had to search and research on our own or even change the business requirement to achieve some goals.
Via this answer I am not intending to promote or demote any software but just want make people aware about the product we are using so they can make wise decision.
The last time I looked into this, Spices.Net Obfuscator looked like the best thing on the market.
No, I don't work for them. :)
I use smartassembly. It is simple to use and also has the ability to send crash reports back too you built in.
The obfuscators others have mentioned are likely very good.
An alternative approach you might not have considered is to code some of the core business logic using a language that is fully compiled to machine code, such as C++.
The benefit of doing this is that it makes it far more difficult for someone to decompile your code. A drawback to this is that you have code in two languages to maintain. This might not be the best approach for your situation, but is useful in cases where only a small part of the code needs to be obfuscated while the remainder of the code is UI fluff.
As an example, your medical software package might be performing edge detection of say, certain glands for the purpose of telling a doctor the size of said gland. The algorithm for calculating the size of the gland from a bitmap image would be contained in a DLL written in C++.
to answer your question about the C++ wrapper around the .net code; I dont think it would work, because when you deploy the application the final c++ dll and .net dll containing the business logic code will be separate entities and the ones who want to get to your business logic would still be able to just pick out the .net dll and peek inside.
you might want to consider Remotesoft Salamander Protector
this is much better than anything else in that it makes it impossible to decompile to the high level language.
Of course, anybody who is an expert can spend enough time with your software and figure it out because it does decompile some,but it hides all the set and get methods
So, they can get a peak,but that is about it. they have to figure out the rest which lowers the probability of anybody just cracking it.
hope this helps
Writing on this thread after a long time. We have purchased a software called Intellilock which is helpful in preventing decompilation, obfuscation and also has a strong licencing module.
We did not go for .Net Reactor even though it has more prevention controls as Intellilock was serving our purpose well enough.
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
My background: Mostly C programming. I have some (very recently...last 2 months) acquired JAVA (novice) skills. All my limited experience is based on developing for linux.
I would like to do some excel programming for work purposes. My main interest is in starting to create "dashboards" and charts/reporting from excel sheets as I'm sick and tired of updating many sheets by hand. I'm lazy so I love to automate wherever I can :-)
Which one of these "new" languages (for me) would you recommend to learn? I'm also hoping that if/when I'm getting more familiar with Windows/MS Office environment I can do more "powerfull" things.
If your main goal is to optimise your Excel tasks, then VBA is the language to learn.
The good thing is that if you have any programming background the learning curve is extremely straightforward.
Just run "Record Macro", perform a task, then look at the code that was generated. You've got a working example to learn from.
I personally prefer C# as a language, but in terms of released versions, VB.NET is a better language to use for Office interop. C# 4 has improved this situation a lot though, with named arguments and optional parameters, ref argument faking and COM PIA linking.
If you can use C# 4, that might be the best option for you - but if you're stuck with fully released versions, you might want to go for VB.NET instead.
If you want to dig straight into excel automation, I'd stick to VBA. If you're more interested in extending your knowledge, I'd choose one of the .NET languages, probably VB.NET.
C# seems to be more prestigious/popular, but it's also closer to what you already know. If you learn the .NET Framework using VB, that and your C/java syntax means you'll be able to read C#. It would also give a smoother transition to VBA if you change your mind.
Since you know Java & C, C# should be the easiest to learn. More jobs for C# skills too, if that's important to you.
All of the answers given are sensible, but I'm not sure they're realistic. Yes, Microsoft have been wanting to get rid of VBA for some time now, and I'm sure they dearly wish that Visual Studio Tools for Office would take off; and yes, VB.NET and C# both support something called classes (using object-orientated programming) much better than VBA does.
HOWEVER ... the world uses VBA! Particularly for Excel solutions, I'd guess about 99% of all systems ever written use VBA. So personally I'd learn VBA, helped by the fact that:
You can record macros to see how to do things; and
It's built into Excel (no need to buy or install any other software).
I've written a VBA tutorial online which I hope will help, full of example code and diagrams. Let me know what you think of it, if you should use it.
PS It might seem that my advice is somewhwat biased, but it isn't. We train on VSTO, C# and VB.NET, and my personal preferred programming environment by some way is Visual Studio (VBA drives me mad when I have to revert to it now). However, that's the result of nearly 20 years of learning! For a new programmer, VBA is much simpler to learn.
Microsoft plans to get rid of VBA sometime in the future. Support was already dropped from the Mac version of Office 2008 for example. It way stay around in the Windows version for some time, but no significant new development will be done on it.
Seeing you have C and Java knowledge, and considering you're starting fresh, I'd definitely go with .NET. It's simply the better investment for your time.
Like Jon Skeet says, C# (4.0) is probably your best option if you don't mind using beta software.