As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am getting started doing ASP.NET on my Mac using Mono, and I'm wondering which databases people have used in this setup. I'd be looking for something that is easy to set up, as this is just for fun and for continued learning of ASP.NET.
For your purposes, the SQLite version that comes with Mono (see here) seems perfect, no much how wonderful PostgreSQL (or, I guess, even MySQL;-) might be;-).
SQLite is everywhere (in .NET, in iPhones, comes with Mono, comes with Python, it's in Android, etc, etc), so getting familiar with it can hardly hurt anyway!-)
You could use MySQL - it's well documented and has .Net drivers. See http://www.mono-project.com/Database_Access for a comprehensive list with driver info.
Postgresql via MacPorts. Npgsql as the .Net driver.
Whoa... SQLite isn't installed with Mono, I don't believe; just the connector is. From the same URL the accepted answer uses to say it's there already...
Prerequisites
If you do not have SQLite, download it. There are binaries for Windows and Linux. You can put the .dll or .so along side your application binaries, or in a system-wide library path.
If you want a database that works on OS X (and elsewhere) without change or prereqs other than a recompile, C#-SQLite, an unofficial, line-by-line port of SQLite to C#, might be worth a look. There are issues with compilation (one example here from May of last year), but with some research it apparently does okay (initially it had some P/Invokes that prevented compilation on OS X (and also Silverlight) which have been removed).
Better example of compilation problems as well as some reason for optimism here:
What steps will reproduce the problem?
Compile database and SqliteClient and SqliteClientTests (works fine)
Run Test No. 1 using command "mono SqliteClientTests.exe"
Cry!
...
Comment 1 by project member market.n...#gmail.com, Sep 15, 2011 Have
you contacted Miguel de Icaza at mono about this? I forget the
details, but there were some compiler flags he set to get it working.
He told me last March that it was working. Maybe the 3.7.7.1 code set
broke some things. Did you try the 3.7.5 or 3.7.6 versions?
So do your homework, but I think once you get a good build, this might be your answer.
I've used: Firebird, MySql, SQLite, Oracle and even Postgres long long ago.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am currently a Web Developer / Designer. I am currently moving towards mobile development. Though I use and like Android I think Windows phone 8 has a really good future and would like to start developing for it.
I heard that it is possible to develop applications using HTML5, CSS and Javascript which was really exciting for me as it means I can get started really easily as I am really good in these. But I am a little doubtful whether it is really possible to access all the available features of the API using Javascript.
Will javascript based applications get really restricted like the current ones which run from the browser ? Or are they as powerful as the ones we are able to develop using .NET or Silverlight ?
Please remember that I am talking about developing for Mobile phones and Tablets based on Win 8 and not desktops.
But I am a little doubtful whether it is really possible to access all the available features of the API using Javascript. Will javascript based applications get really restricted like the current ones which run from the browser ? Or are they as powerful as the ones we are able to develop using .NET or Silverlight ?
With respect to Windows 8, JavaScript Metro apps get access to WinRT APIs, excepting XAML-related stuff (as you're supposed to be using HTML5/CSS3 for UI rather than XAML) and other APIs that duplicate functionality that is already standardized as part of HTML5. So, yes, they are as powerful.
No-one can tell you about any future version of Windows Phone, because there hasn't been any official information publicly released on that.
Right now, there is no (final) information regarding which development languages Windows Phone 8 will support.
Windows Phone 7 supported development in Silverlight and XNA, so XAML is what we currently have.
Windows 8 uses XAML and HTML5 + CSS + Javascript for development; probably, Windows Phone 8 will support the same, but right now this is just speculation!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In a desktop .NET application, the standard option for implementing a local relational database is to use SQL Server Compact Edition, and then of course there is the possibility to use SQLite and other third-party engines.
What are the options available to a .NET Metro-style application? SQL CE seems to be unavailable - any replacement? In fact, the entire System.Data namespace seems to be gone - so no LINQ to SQL or Entity Framework, either?
What about HTML5 IndexedDB that seems to be available to Metro HTML/JS apps - can that be used from .NET somehow?
Apparently, the Extensible Storage Engine Win32 API (aka "JET Blue") is still available in Metro apps. C++ ones can use it directly via #include <esent.h>. .NET apps would have to use P/Invoke. This does not give SQL or any other sort of high-level relational querying constructs, but it does provide for key lookup, transactions, multiple indices per table, and multi-field indices.
Let's be clear: SQL CE exists in Windows 8. It exists not only in Program Files but in Windows\System32 to seem even more embedded than before. Windows7 doesn't have sqlcecompact40.dll in system32 so this is definitely new. System.Data and System.Data.Linq both live in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.
You can add references to those dlls manually but getting the app to compile is hit or miss. It seems that if you first open your project and do nothing, you can add a reference to those dlls anywhere and compile the app. If you remove the dlls and try to add them back you're hit with a "A reference to '<4.5 framework directory>' could not be added. If by some chance you can't add them via Visual Studio you can easily just add the HintPath manually.
My app now compiles but I also ran into an issue where linking the AppX wasn't working correctly and it gave a cryptic "Payload cannot contain 2 of the same dll" type messages. Like it was trying to include both 32 bit (the one I linked) and 64bit at the last minute. It included DLLs I wasn't touching manually like System.Data.OracleClient or System.Transactions so it was definitely some artifact from the build process I've yet to see again.
The main issue I'm dealing with right now is how to generate a proper connection string since it won't initialize properly without one. SQL CE is likely still looking for hardcoded C:\ references so the ApplicationData samples may not work as desired. I may try to make SQL CE 4 databases in Win7, transfer to Win8 and simply reference them locally but I'm kind of in the same boat there too. This | | close!
Please feel free to comment regarding any issues you run into and I'm definitely down for some offline collaboration if anyone would like to pool resources. This is definitely a thick forest of beasts and going it alone is proving a lot more challenging.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If you are sticking with Delphi for Win32, what do you use as GUI framework, in order to approach the versatility and performance of the WPF framework on .NET?
There are some alternatives out there, such as DXScene, but it appears to have a problem with font clarity. Graphics32 and AGG are excellent low-level libraries, but lack a high-level design environment or IDE-plugin.
What do you use to implement a modern vector-based GUI?
Last year, I would have answered about DXScene - see also this question.
But now, wait some weeks, and try FireMonkey, which is DXScene bought and integrated into XE2 by Embarcadero!
Just one huge point: WPF is Windows only, whereas FireMonkey is cross-platform - it will run under Mac OS X and even iOS. And in the next XE3 version, it should also be able to create desktop Linux application (just as DXScene did). It uses Direct X under Windows, and Open GL on other platforms (even iOS).
It's not VCL-based not "native control" based, but draws its own vectorial controls using a "all-is-container" modular approach. Thanks to an internal "theming" engine, it is able to render controls as native under Windows or Mac OS X. It won't use a XAML language, both some controls on standard IDE forms, or runtime-created controls, if needed.
The Delphi VCL still works just fine for me, and without WPF's infamous "learning cliff".
I use VCL and DevExpress for all my GUI needs. DevExpress also have a Skin Library if you need a more fancy UI.
Actually there are no libs which will allow you to use WFP directly in Delphi.
I would suggest you to try and use AGG and build your own lib for such tasks or use AGG's commercial descendant.
Sorry Domus, but WPF is not known as a "performance" framework also isn't hardware accelerated. WPF is a layer over windows 3.1 common controls.
In the other hand Direct2d is hardware-accelerated 2-D graphics API that provides high performance and high-quality rendering for 2-D geometry, bitmaps, and text. And is available in Delphi 2010.
http://msdn.microsoft.com/en-us/magazine/dd861344.aspx
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
We're starting a new project and are trying to decide to use either Windows Forms or WPF.
I've read some of the other Stack Overflow posts, and realize that WPF has some advantages in the data-binding and appearance areas, but also has a steep learning curve and fairly immature tools and controls.
We would like to better understand if Microsoft is planning on stopping new development of the Windows Forms technology and forcing all new development to eventually go to WPF, or if both technologies will be maintained and improved. (Or are they just going to wait and see how it goes before making up their mind?)
Currently, it seems like WPF is not necessarily the best way to go for line of business applications that don't need extra bells and whistles in the UI. However, it would be good to know if WPF is something we'll need to embrace sooner or later.
This is partially a reasoned argument, and partially a heart-felt rant....
WinForms is based on the user32/GDI technology that has existed since the dawn of modern Windows. It is not going to go anywhere, in all senses of the phrase: it won't get new features; it won't get support dropped.
Or maybe it yet will. The charting API in .NET 4.0 is new and written for GDI, not WPF.
In general, Microsoft has a history with new technologies that looks like the following:
Invent new API.
Innovate with that API for 2 or 3 product cycles.
Realize that continuing to innovate means making unreasonable concessions to backwards compatibility or having realizations that the technology didn't originally address.
Invent new API by wrapping or leaving the existing API around. The existing API doesn't disappear, but new stuff doesn't use it, either.
RDO -> DAO -> ADO -> ADO.NET -> LINQ to SQL -> Entity Framework, toss in some ODBC ... there is a treasure trove of "dead" and wrapped technologies that are still usable and still exist today. These are data access technologies, but the same idea applies; UI frameworks last a little longer because they are the most visible areas of applications.
If I put my Nostradomus hat on, I can safely say that when .NET, oh, 6.0 is out in 2015--which sounds far away but is as close as we are to 2003--WPF will be as "dead" as Windows Forms because some other nifty managed interface will have been created that smoothes over all of the as-yet-undiscovered mistakes and inconveniences of WPF. Who cares? Everything we are yabbering about today will be deprecated by then. (Something is going to have to give in .NET 5.0 anyway because the framework is getting comically large.)
If anything, the thing that Windows Forms has going for it is that it's based on the technology that has existed for well over a decade, and that inertia is not dying anytime soon: the browser you are typing in is using GDI, the taskbar is using GDI, your instant messaging application is using GDI, the new Ribbon control in Windows 7 is using GDI, the $60 printer sitting your desk is using a GDI printer driver, the Windows CE applications running on your phone run a port of Windows Forms and GDI, the new Event Viewer in Windows Vista is using Windows Forms, and there is a large third-party component community behind the Windows Forms platform--WPF is a very small, niche product that only exists in the managed world, which is itself smaller than its unmanaged counterpart.
To this end, I feel that all of these "WinForms vs. WPF" discussions are blowing things out of proportion; the technologies are not mutually exclusive or inferior/superior, as much as Microsoft marketing might have us believe, and Microsoft's developers are smart enough to realize this. They are simply different and one of them happens to be older. If we didn't consider this periodically, we would have all listened to Gartner in 2005 and stopped building Windows applications entirely and moved everything to AJAX on the Web ... with our SOA interfaces ... that expose an alternative REST interface ... that use a TDD DDD model on that backend ... abstracted from the database by an ORM.
Being so eager to abandon a technology for fear of its deprecation only assures our clients that we will maintain a constant level of inexperience and incompetence at programming software solutions.
WPF is part of the future, to be sure, but it's not THE future. Personally, I'm on the fence to see if WPF "makes it" in the UI technology sense that previous data access technologies haven't, although Visual Studio adopting it in 2010 is a pretty comforting sign that Microsoft is actually serious about it by dogfooding it in a flagship product.
To sum up: if you are building a LOB application, I wouldn't feel guilty about using WinForms. If you need an advanced layout scenario, WPF interop is always available to you, just as one enhances a regular Web site occasionally with a Flash object. But for anything else, you owe it to your client to come up with a Good Reason for transitioning the whole team and shell to WPF; Windows Forms has its problems, but half the battle with any platform is knowing what the problems and limitations are, and most of the world (including Microsoft) is still learning WPF.
WinForms won't be deprecated until Win32 is ... which could be quite sometime!
(Remembering that WinForms is basically an abstraction over Win32)
WPF on the other hand has few direct dependencies on Win32 so could potentially form the basis of a "fresh start" UI layer on a future version of windows. At which point I would imagine Win32 (and thus WinForms) will be completely ditched and only available through virtualization. As I said this could be along way off :)
Microsoft's support policy for the .NET Framework and all classes within it is 5+5: 5 years of mainstream support after a release, and then 5 years of extended support is available, or a fee.
With the .NET 4.0 update, including all the WinForms stuff, being released in 2009, you will get 5 years of mainstream support, to 2014 for any WinForms app built on .NET 4.0.
It's likely whatever comes after .NET 4.0 will include WinForms, too, in which case the clock resets.
This 5+5 policy applies to all business-related infrastructure software: Windows, Windows Server, SQL Server, Visual Studio, .NET, and so on.
The point is, you won't have to worry about lack of support for WinForms.
But, the prior posters are correct - the advancements are going into WPF.
I wouldn't worry too much about long term support. WPF may be getting all the love lately, but there's too much WinForms code out there to abandon support. After all, even MFC is still getting updates with each Visual Studio release.
I think Windows Forms will continue to be maintained by Microsoft, but improved upon only in small ways. All of the hot new innovations will go to WPF. Windows Forms is in a similar position as LINQ to SQL. LINQ to SQL is a tight, compact, fast ORM that is awesome, but Microsoft is throwing its weight behind the Entity Framework.
Windows Forms is great for what it is, and what it is used for, which is small, tightly-wrapped applications. It still has many years of life left in it.
If you want an application that will (more) easily port between a web interface, a WPF interface, or a Silverlight (or even a Flex) interface, Windows Forms is probably not for you. These other interfaces use standards-based markup, and an architecture that lends itself better to enterprise development.
I certainly wouldn't call WinForms dead... but I also wouldn't write a new project in it. I would write all new projects using WPF for a myriad of reasons. The biggest is that if you use WPF/XAML, your porting efforts to Silverlight will be much easier.
I went to a WPF preview camp in Redmond a couple of years ago, and I asked this same question to one of the folks working on Crossbow (WPF/Windows Forms interop). His response was that Windows Forms will be supported for the foreseeable future, but could make no guarantees.
Given that, I think you'll be OK basing your application on Windows Forms knowing that you'll have some level of support for the next version or two of .NET (for example, 3-5 years).
I would personally bet closer to 10 years considering Microsoft's continued support for Win32. You may not get boatloads of new features with each release, but you won't be dropped, either.
In any case, I would actually be more concerned with Microsoft's shift from rich-client technologies to web-based technologies, but not enough to ignore opportunities to create compelling applications in either case.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Taking advice from this post, I purchased a copy of 'The C Programming Language' and am happily reading my way through.
However, all the stuff I've written in the past has been interpreted, and I have no idea where to look for a good C compiler or an IDE (is there even one?). Google searches throw up a lot of results for C++ compilers, which I don't think is the same thing? Haha. I was wondering if there is a compiler or IDE for C that's regarded as an industry standard (kinda in the same way that Zend Studio is pretty much the IDE for PHP), or at least one that is generally considered to be a good quality product.
I'm surprised no-one's mentioned Pelles C. Great little C IDE for Windows; includes an LCC-based compiler. That said, NetBeans 6.5 has decent support for C and C++, and Code::Blocks is well worth a whirl.
Well, Visual Studio is the standard on Windows, and there are free versions available. However it does have a bunch of Microsoft specific extensions.
For learning though, developing console apps are pretty easy and also fairly close to the standard K&R style C.
However, way back in the day I used to use Watcom, which was also pretty good for the time. It's a lot more sparse than Visual Studio, but that can be an advantage for a beginner.
I believe it's also available for free these days at http://www.openwatcom.org/index.php/Main_Page
I'd probably recommend starting with that, if your main O/S is Windows.
Edit: new live url
Most people use Microsoft Visual Studio for development on Windows. You can get a free version here:
http://www.microsoft.com/express/download/.
Usually GCC is used on Unix, and is typically included with the OS.
C and C++ are very similar, but C++ allows classes. Most C++ compilers will compile C code.
I used DevC++ almost exclusively while I was in University for C\C++ programming. It comes bundled with the MinGW compiler. It's pretty easy to get set up and rolling. Other than this, my only other recommendation would be Visual Studio.
Almost all C++ compilers will compile C code.
I would recommend using Microsoft Visual Studio. There is a free version of it.
Most C programmers like to have their own editor and choose a compiler that fits their project. That is why you can download multiple different compilers for C and not so many built into IDE's directly.
It is easy to use editors like Editplus or even Notepad. Some of the fancier editors have syntax highlighting and can run commands in a command window for you.
IDE's usually support multiple languages as well. So when you are tired of C and want to move on to Python, Java, C++, some IDE's can help you do that. I would look into these:
Eclipse :: http://www.eclipse.org/callisto/c-dev.php
Microsoft Visual Studio :: http://www.microsoft.com/express/
GCC (GNU Compiler) and vi/emacs (or pico for uber-newbies)
Addendum: remember C is NOT a subset of C++, so a c++ compiler is not necessarily appropriate.
I recommend Quincy when you are just learning to program in C/C++. Simple to use and created for easily trying out small C/C++ programs.
You can download the Digital Mars C compiler for Windows for free.
Another good IDE is CodeBlocks, and its cross platform. Give it a try you might like it. I used it for a while an it gave me good results for what i was doing ( an image editor in C ), but it had some bugs.
For unix developing i've always liked using gcc plus an editor... it just makes it fun ( after you get use to it ).
When it comes to c/c++ compilers on the Windows platform there are quite a few to choose from.
And when it comes to and IDE, the Zeus IDE can be easily configured to work with any of them.
I used DevC++ when learning C years ago. It was a great tool, although I haven't seen it in a while so I'm not sure what state it is in now.
http://www.bloodshed.net/devcpp.html
For the record, I used TCC, the Tiny C Compiler, to quickly test small code. It can generate exe and DLLs.
You might need to download the Windows headers: it has a limited subset, you might want more.
Digital Mars also has a free C/C++ compiler of reasonable size.
GNU C is pretty much an industry standard, even if its a unixy compiler.
You can also use Visual Studio, but keep in mind it doesnt support C99 very well.
Other choices are out there, like pcc (I really like this one), llvm (also very interesting), etc, but those usually require some level of enthusiasm.
The free country website has a list of free C compilers. Many of which work on Windows.
You could use a C++ compiler, such as gcc, to compile your C code. Here's a good article with links to free C compilers/IDEs:
http://computerprogramming.suite101.com/article.cfm/freeprogrammingtools
Simply because the white book is influential, doesn't mean it's a good learning resource!
It is possibly the worst way to learn a language from that has ever existed. On top of that, last time I checked it was unreasonably expensive.
It's a complete language definition, and is good at that (which is why it truly is one of the most influential programming books). For a long time it actually was THE definition of C.
You might consider a second book on the subject.
That said, you should try quite a few different IDEs and see what you are happy with.
In fact, at first you might want to get used to vi/emacs/notepad/make and command-line compiling, this will get you a much stronger understanding of your environment (and if it's not understanding you're after, then you are barking up the wrong language-tree).
As you are investigating different IDEs, I'd give Eclipse or Netbeans with a c plugin a try. They are going to be the most complete and reliable IDEs (except, probably, for Microsoft's) and are platform independent so you won't be left in the cold when you decide to go to the Mac or Linux.