I'm planning on writing a "medium-size" WinForms application that I'll write in C#, .NET 3.5. I have some "generic design questions" in mind that I was hoping to get addressed here.
Exception handling in general. What is the best way to handle exceptions? Use try/catch blocks everywhere? this?
Localization. If I'd want to have multiple language support in my application, what should I use? I find the "satellite assemblies" to be a very... well, "bulky"-seeming solution - I don't want a resource file "hell", and I don't want to input translations inside the VS UI.
Storing data locally. Previously, I've used System.Data.SQLite on a project, but I found myself wondering if there's something else I should consider.
Anything else I should keep in mind?
Thanks(?)
1) Don't catch any exceptions. The vast majority of them tell you about a bug in your code, you'll want to know about them right away. If during testing and deployment, you find error conditions that you think you can handle (there aren't many of them), you can always add the try/catch block. If you plan on handling exceptions, be sure to liberally sprinkle try/finally blocks in your code so the state of your classes is preserved even if there's an exception that prevents cleanup code from running. There is no notable cost to using try without catch.
2) Satellite assemblies are not bulky. Just a small DLL in a subdirectory of your deployment folder. No special code is required, everything is automatic. Most of all, it is a standard solution. You can send your .resx files to a localization service and they'll use standard tools (like Winres.exe) to provide you with the translations. Asking them to deal with something custom is going to be expensive and potentially troublesome.
3) Alternatives are SQL Server CE (same approach as SQLite) and SQL Server Express. The latter gives you the most bang for the buck, but must be installed. That isn't hard.
4) It depends on your target audience, but if look-and-feel is at a factor in a buying decision at all, hire a UI designer. S/he'll catch UI bloopers and make it look spiffy.
#1 - If you care about performance of your application , avoid try/catch. Use some profiler for example the one from RedGate (ANTS - it's not a freeware sadly) to see for yourself that try/catch block consume a lot of CPU time , especially if there is a need to jump into "catch". Just try to find any other way around , .net has got a lot other methods you can use to make shore that no exception will occur, I know it's easier to use try/catch but decide what is your aim.
#2 - I guess that you can use resource files that are compiled with you application so you won't have any separate file if that is what you're asking ?
#3 - I really have to answer that one :) , personally I think there is no better/more comfortable way of storing data locally than to use XML , as it was mentioned before, you can use LINQ to XML to query this file , which is extremely simple. It's small , fast , easy to create , maintain and what's more important you can send it trogh the Internet without any problems that may occur using other ways of storing data , example - firewall or any ISD won't be a problem because it's basically a text file. I simply love xml.
Was that helpfull ?
Regarding first question - have a look at Enterprise Library Exception Handling Block. Microsoft did a great job at providing documentation and code to solve this problem.
Regarding other question (especially #4) it is hard to recommend something without knowing details of your application.
I pretty much have the same answer as aku for the first question, you might want to take a look at the Enterprise Library in general since there are several useful blocks such as the Logging and Validation blocks.
Can't help with the second since I haven't worked on any projects that needed to support localization of any kind.
Without a better idea of what kind of data/application you are developing it is kind of difficult to recommend local data storage. A couple of thoughts that I have (no particular order) are:
An Xml file is portable and can be manipulated with LINQ->XML.
Are your objects stable? You could always serialize them.... (Although I don't recommend this)
Although local now, would the data (some or all) be better shared on a server with other users in the future.
You mentioned SQLite, have you considered SQL Server CE?
What kind of query performance does you data layer need to support?
As mentioned before, Exception handling block
Not done much localizaton, but the
resource handling in VS 2008 is much
better than VS 2003
SQL Server Compact Edition,
VistaDB and Codegear
Blackfish are product that you
might investigate. SQL CE is free
but the others cost money
Why not download Visual C# 2005 or 2008 Express Edition?
Designing is easy
Open Visual C#
Open Create
Open Create Project Dialog
Design it
Code it
Publish it
Download 2005 ->
Download 2008 ->
Related
I have a program, which watches a folder on the server. when new files (flat file) come in, the program (C#) read data, bulk insert into the table. it works fine.
Now, we extend the system. It means the data files could be in different formats (flat file, csv, txt, excel..), or with different columns (we need map them to the columns in the table).
my question is: is C# the best choice for this? or, SSIS is a better choice?
Thanks
I wouldn’t necessarily choose one or the other but choose depending on the file type and the amount of processing. For some file types its probably easier to go with C# and for some other SSIS works better.
Do you have someone on your team who is good with SSIS? It’s much easier to find a C# dev to do the job for you than to find someone who knows SSIS.
How likely is that requirements/formats are going to be updated in the future? That’s also important thing to keep in mind.
I do agree with what others said that SSIS is more powerful and offers support for more complex transformations but the questions is do you really need this?
It's depends on your context. Different format should not decision go to SSIS. With solution C# program: you can continue go with it because it run stable before. Easy to deployment, specific into your domain, easy to configuration as well.
With solution SSIS: The configuration more complicate required developer has deep knowledge into SSIS. The administration fee required more than C# program. However it easy to visual (has diagram for you see the flow integration more easier).
From my viewpoint, if the integration process does not required complicated about business rule you should go with C# program. Otherwise, SSIS more powerful if integration process required rules complicated. Hope this help.
In C# application I guess you are using the SqlbulkCopy component and compared to SSIS its not that powerful. So if your data size becomes huge,then C# application will become slower.
If you are familiar with SSIS,my suggestion is to go with SSIS. In SSIS,you can implement end-to-end solution as you have developed in C#,right from checking the files in a specific folder to loading the data into database.
I know this is very vaque question but still I am asking.
Is there any one I can convert my existing WinForm built in c#.net and DB as SQLSERVER 2008, to andorid application ?
If no, then is thr any easier way to built an app as I am not familiar with any Mobile Application tools.
Generally, no. The languages are somewhat similar, but the way the UI is built is vastly different and will have to be rewritten from scratch. Also, database access differs. I actually doubt that Android have libraries required to "talk" to SqlServer. Even if it managed to talk over some generic ODBC layer, still the DB-access will also differ very much. I assume this would consist of more than 80% of your application - so it can safely be estimated that whole application cannot be converted, and a new application has to be written. Of course, some SQL queries might be reused, some application classes might be usable too (if written in an enough platform-independent way, so they can be translated to Java)..
No there is no way to do that in easy way.
Android development is similiar in UI level to WPF (you can find some simliarities) + you have completely different behavior model as you're talking about mobile development.
In short, if you want to continue with C#, you may think of picking Mono Droid.
It's payed.
This is not easy as far as I know. If you want the conversion for free you should rewrite it in Java using the Android SDK (run on Dalvik - a custom VM). As stated above, you will have little effort learning it if you already know C#, you could also use Mono Droid or hire a developer if you have the possibility to do so.
My team is developing a new application (C#, .Net 4) that involves a repository for shared users content. We need to decide where to store it. The requirements are as follows:
Share files among users.
Support versions.
Enable search by tags and support further queries such as "all the files created by people from group X"
Different views for different people (team X sees its own content and nobody else can see theirs).
I'm not sure what's best, so:
can I search over SVN using tags (not SVN tags of course, more like stackoverflow's tags)?
Is there any sense in thinking of duplication - both SVN and SQL - the content?
Any other suggestions?
Edit
The application enables users to write validation tests that they later execute. Those tests are shared among many groups on different sites. We need versioning for the regular reasons - undo changes, sudden deletions etc. This calls for SVN.
The thing is, we also want to add the option to find all the tests that are tagged "urgent" and were executed by now, for tracking purposes.
I hope I made myself more clear now :)
Edit II
I ran into SvnQuery and it looks good, but does it have an API I can use? I'd rather use their mechanism with my own GUI.
EDIT III
My colleague strongly supports using only a database and forget file based storage. He claims it is better for persistence (which is needed - a test is more than the list of commands to execute). I'd appreciate inputs on this issue, as I think it should be possible to do it this way or the other.
Thanks!
Firstly, consider using GIT rather than SVN. It's much faster, and I suspect it's more appropriate in your use-case: it's designed to be distributed, meaning your users will be able to use it without an internet access, and you won't have any overhead related to communicating with the server when saving documents.
Other than that, I'm not making full sense of your question but it seems like the gist of it might be better rephrased like so: "Can I do tag-based searches/access restriction onto my version control system, or do I need to create a layer on top to do so?"
If so, the answer is that you need a layer on top. Some exist already, both web-based (e.g., Trac) and desktop-based (e.g. GitX). They won't necessarily implement exactly what you need but they can be a good starting point to do what you're seeking.
You could use SVN.
Shared files: obvious and easy. It also supports the centralised locking that you might need for binary files.
Versions. Obviously.
Search... Now we're getting into difficult territory. There is a Lucene addon that allows web searching of your repo - opengrok, svnquery or svn-search. These would be your best starting points for that.
There is no way to stop people seeing what's present in a svn repo, but you can stop them from accessing it. I don't know if the access control could be extended easily to provide hidden folders, you could ask the svn developers.
There's some great APIs for working with SVN, probably the most accessible is SharpSVN which gives you a .net assembly, but there's Python and C and all sorts available.
As mentioned, there are web tools which sit on top of SVN to provide a view into it, there's Trac, and Redmine and several repo-viewers like webSVN, so there's plenty of sample code to use to cook up your own.
Would you use a DVCS like git or mercurial? I woulnd't. Though these have good mechanisms in themselves, it doesn't sound like they're what tyou're after. These allow people to work on their own and share with others on a peer-to-peer basis (though you can set a 'central' repo and work with that as everyone's peer). They do not work in a centralised, shared way. For example, if you and I both edit a test case locally andthen push to the central repo, we might have issues merging. We will have issues merging if the file is a binary or otherwise non-mergable file. In this case you have a problem with losing one person's changes. That's one, main reason for not using a DVCS in your case.
If you're trying to get shared tests together, have you looked at some apps that already do this. I noticed TestRail recently that sounds like what you're trying to do. It's not free (alas) but it's cheap.
I have a pawnshop CRUD app written 20 years ago with INFORMIX-SQL/SE (DOS) which is currently running on DOS 6.22 within Microsoft Virtual PC 2007 on Windows Vista. I would like to modernize this app with a GUI, SQL-based engine and retain its existing functionality. It doesn't require any networking or multi-user capability. I would prefer a product which is royalty-free.
I also would like to quickly re-write it with as little effort possible. Which tool would you recommend?
I'm debating whether to re-write my INFORMIX-SQL app with I4GL (character-based) or another Windows/GUI-based tool.
My app is very robust and has some incredible features which my users are very happy with. Only obstacle which is keeping me from effectively acheiving market penetration is, believe it, my app is char-based and I would like to duplicate the same functionality with a GUI. My feeling is that its quicker for a user to process a transaction with my char-based app vs. having to focus a cursor with a mouse, but cosmetics is hurting me!
I would like to know specific instances of limitations, bugs or drawbacks of using another development tool before I invest considerable amount of time evaling another product. Answers to this question could save me a lot of time and money!
If you visit www.frankcomputer.com you can view a video-demo of my pawnshop app. (CAVEAT: The website's in Spanish, use google translate to get a more-or-less decent translation of the text. Start the video at the two-minute mark, with 720p resolution and full-screen to best comprehend my app.)
If I were doing it, I would probably choose to write a WPF GUI in C# with a SQL Server Express backend database. An embedded database like SQLite might work as well. But the main reason I would choose that is because that's what I'm most familiar with. Someone else would likely choose something else...
I might also choose ASP.NET MVC and make it a web application if that were an option (you say that multi-user is not required, but I say it's not required yet).
Also, if you're not the one who's going to be developing it (i.e. you're going to hire someone to build it for you) then I would say that you should find the developer first and let them choose (or at least have a say in) the technology. If you choose the technology up-front then you're simply limiting the field of developers who'll be able to work with you and there's really not much point in that.
I'd recommend you use Python with a PostgreSQL backend. Now some will think this is overkill, but after watching your video and reading your site (I had to use a translator), I suspect the added flexibility is something you will truly enjoy by going this route.
The reasons I'd argue for this solution are:
Python and PostgreSQL are both great products with amazing communities when you need them.
Both products have a bright outlook in their development paths. Since you obviously spent a lot of time and effort tweaking SPACE, I'm betting you will do the same over the next 40 years. So, the tools you choose now need to be there for you as you continue your development cycle.
They are both free with friendly licenses.
Cross-platform support.
Scalability. You can use PostgreSQL installed locally and connect via socket or scale it all the way up to several servers using load balanced connection pooling.
Security.
Data integrity. This includes how easy it is to make your whole environment easy to backup and thus easy to restore in the event of a catastrophe.
Whatever tools you end up choosing. I wish you the best in this project. I can tell you are working on something you truly love and that is something more of us should strive for!!
Based upon your answers and your emphasis upon time to make the changes and that you don't seem to want to change the Application at all but it is being forced upon you by then you should certainly evaluate Genero from 4js.
This will allow you to utilise your existing code but provide a nicer looking front-end. You can also maintain a single codebase supporting both character and "Gui" clients.
Choose whatever language and technology is easiest for you. If you need DB access and a short lead time it sounds like Java or Visual Basic would be best. Both have plenty of free tools to get you started.
The top languages tags in StackOverflow are C# (by a long margin), then Java, PHP and DotNet, followed by C++ and Python. Some of that will be skewed by the Joel & Jeff origin of the site, but any of those is more than capable of the task. Personally, I'd go with Java or Python but I don't like being tied to the Microsoft stack.
wxWidgets and QT might be options for the GUI components.
Of the databases, mysql, SQL Server Express or Oracle Express Edition are all free and robust. SQLite is good enough for most single user applications though. I'd put this at the bottom of the 'importance' list. For small-scale single user apps, you should be able to chop and change DB platforms without much hassle. The biggest relevance would be in how you actually backup/copy/restore data in the event of disk failure or corruption.
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
I have the task of developing an application to pull data from remote REST services and generating Excel reports. This application will be used by a handful of users at the company (10-15). The data load can reach 10,000-200,000 records. I have been debating whether to use Python or C#...
The only reason I am considering Python is because I am familiar with it and it would be less of a risk.
Personally I want to try use C# since this would be a good opportunity to learn it. The application is not too complicated so the overhead of learning it won't be too much... I think.
Are there any issues with C# that I should be concerned about for this type of program? The users run Windows XP... would users not having .NET installed be a major concern?
Thanks in advance.
EDIT:
I guess I need to stress the fact that the end users should be able to run the application without installing additional libraries/frameworks.
Why not IronPython which merges the two worlds together?
If you want to learn C# and you don't have such a limited time constraint, now might be a good time to try it. Also, though I haven't done Excel work with either Python or C#, I would expect it to be easier to work with Excel files with a Microsoft product rather than Python. If you're just dumping data in CSV format to a file, though, either Python or C# will work fine.
If you want to try something even crazier, you can use IronPython such that you'll have .NET resources available but you can still write in Python.
I would normally say, use what you know.
However, here you may have some performance issues using an interpreted language. I, myself, would use C#. If you want to learn it, now is as good of a time as any.
However, if your own cost/benefit analysis reveals that you would be better off in python, use that.
.NET will be required for C# on windows, but you can use the .NET Client Profile to make the install pretty painless.
I realize this is an old post but I guess I have some pertinent information for anyone coming across this in more recent times, as I have.
The Python library, Openpyxl has worked well for me for manipulating and creating excel files in my desktop based automation scripts.
http://openpyxl.readthedocs.io/en/default/usage.html
It is accessing the file directly from my understanding, unlike the Interop technique in c#. So wherever it runs, you wouldn't need Excel installed. If you're trying to get something on a server it might be an issue getting a licensed copy of Excel or ensuring it exists if your user is running this locally.
Using C# you have the full features of visual studio to help code, such as the code completion, debugging tools and error highlighting. However you can get most of that with Python in Visual Studio, though I've found it more complicated trying to get the right version of python tied to the project and whatnot.
In C# you can easily compile an executable whereas I believe you'll need to mess with loading some Python libraries to get close to a similar local executable with dependencies comparable to the C# output.
If the users have to install a C# client then not having .NET installed would be an issue. You can package the installer so it downloads the .NET runtime, but depending on what features you use it could be quite a big download.
If your application is web based then all the C# code runs on the server and just delivers HTML to the browser so whether .NET is installed or not shouldn't matter.
Integration with Excel will almost certainly be simpler from C#. Given the requirements "Windows only" and "Integrates with Excel", it would seem a simple choice that C# is better suited to this individual problem.
And, no, users' not having .NET is not a concern compared with Python as the alternative. The Dot Net framework is a standard part of Microsoft Update. In contrast, Python will almost certainly not be there on the average end users' machine. In your case, with an internal app, that last point might not matter of course.
If you are doing any kind of HTTP work with C# make sure you take a look at the new HttpClient library that is in WCF REST Starter Preview2. Ignore the name of that download, the HttpClient part can be used independently of WCF.
It is a WAY better client than just using HttpWebRequest.
If you do a web based application not having installed .NET in the client machine wont be a problem .. but I suppose you dont want to try both C# and web development at the same time
It is easy with Python to pull data from a web server, parse the JSON or XML, and generate some kind of report. If you need really good Excel integration (for example, your output is supposed to be an Excel spreadsheet that includes numerous graphs) C# might be better, but Python is still possible; there is PyExcelerator for writing rich spreadsheet files, and there is Python support for COM if you want to use COM to talk to Excel.
With Python it is also very easy to make a stand-alone executable, for example with py2exe.
This sounds like a batch tool, one that won't have a GUI; I think I would write it in Python if I were you, unless I really wanted a fun project to help me learn C#. But anything with a GUI, C# is probably better. (I haven't done GUI development with Python, but I have seen comments here and elsewhere that the performance of Python GUIs tend to be slow.)
The answer probably has more to do with the circumstances than the question of which is the better language for the task at hand.
If you have no prior C# experience, it's probably not a good idea to jump into it now and learn it as you go along. Syntax differences are trivial to learn, mastery is defined by knowing the dirty details and how to use the language's strengths to get the job done.
If you have plenty of time and starting over a lot is NOT an issue, or you have experience with a language that is paradigmatically very similar to C# (say, Java or C++), you could probably afford to take the risk and adapt to the new language very quickly.
If you don't care about efficiency (e.g. it's a pet project, you don't care much about your job or efficiency simply isn't important), try C# just to learn something new (always a good thing) or stick to Python to make sure you won't have to adjust your thinking too much (always a source of vulnerabilities and misunderstandings).
If you definitely want to use C#, you should play around with it in your "free time" (not necessarily at home, but preferably at work when there's nothing else to do) and thus build a skillset you can use once you have to start with the actual project. This way you'll already be familiar with the paradigm (to use the term loosely) and encounter less problems where they count.