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.
Related
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 8 years ago.
Improve this question
I am trying to find an API within WinRT that will allow me to create a local database that can be used to store data for an occasionally connected application. I am looking for something like SQL Compact Edition.
I have seen various messages on various boards indicating that there either
(a) will be no local databases whatsoever
(b) no local "server" databases (i.e. SQL Express type instances)
(c) A local database code named "Jet Blue".
Does anybody have a definitive answer to this? I do not want to start down this road if it is blocked.
SQLite is now officially supported. See Tim Heuer's blog for details. For simpler solution with less data you can use http://winrtdatabase.codeplex.com/
You might want to have a look at SQLite3-WinRT, a wrapper for SQLite that we wrote to use it in a Metro-style application. It contains a version of SQLite that uses only WinRT-compatible API, and a WinRT component to use it in C# and JavaScript apps.
There is no SQL CE available for Metro.
a) will be no local databases whatsoever
This is not true. SQLite should be able to run on WinRT. You can download the code here and include the two main files into your WinRT project. To compile and pass certification you will need to make sure you are using the correct WinRT replacement calls for the Win32 calls that are not supported. The 3rd party solution Bob mentioned is a WinRT wrapper it doesn't include changes to SQLite to pass certification.
(b) no local "server" databases (i.e. SQL Express type instances)
It seems unlikely there will be SQL Express for metro.
(c) A local database code named "Jet Blue".
If you mean Microsoft Jet Database engine, yes that seems to be supported but I would rather use SQLite.
Also remember if you are using HTML/JS you have the option of using IndexedDB
There is no (built in) database according to this
http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-930C
There are 3rd party solutions coming out or are already out. CodePlex has one -- http://sqlwinrt.codeplex.com/
The other option, which requires some work on your part, is to proxy your database access through a web service.
Do you really need a "store data for an occasionally connected application"? This sounds a little overkill to me. Why not serialize the data (various options) to storage yourself?
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 trying to get my head round the new Windows 8 Runtime that is used to create Metro style apps. I know you can use it with XAML and it is based on .NET so C# and VB.NET can be used to write the apps, but then it seems to have something to do with HTML, CSS, DOM, and JavaScript.
Can someone explain what it is in a few paragraphs, in terms that a .NET UI programmer can understand? (I am missing something “key” that is necessary to understand it.)
We all know that WPF, Silverlight, Windows Forms, etc. will keep working under Windows 8 (and Windows 10) on at least on Intel systems, so please don't tell me that...
At the lowest level, WinRT is an object model defined on ABI level. It uses COM as a base (so every WinRT object implements IUnknown and does refcounting), and builds from there. It does add quite a lot of new concepts in comparison to COM of old, most of which come directly from .NET - for example, WinRT object model has delegates, and events are done .NET-style (with delegates and add/remove subscriber methods, one per event) rather than the old COM model of event sources and sinks. Of other notable things, WinRT also has parametrized ("generic") interfaces.
One other big change is that all WinRT components have metadata available for them, just like .NET assemblies. In COM you kinda sorta had that with typelibs, but not every COM component had them. For WinRT, the metadata is contained in .winmd files - look inside "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata\" in Developer Preview. If you poke around, you'll see that they are actually CLI assemblies with no code, just metadata tables. You can open them with ILDASM, in fact. Note, this doesn't mean that WinRT itself is managed - it simply reuses the file format.
Then there are a number of libraries implemented in terms of that object model - defining WinRT interfaces and classes. Again, look at "Windows Metadata" folder mentioned above to see what's there; or just fire up Object Browser in VS and select "Windows 8.0" in the framework selector, to see what's covered. There's a lot there, and it doesn't deal with UI alone - you also get namespaces such as Windows.Data.Json, or Windows.Graphics.Printing, or Windows.Networking.Sockets.
Then you get several libraries, which are specifically dealing with UI - mostly these would be various namespaces under Windows.UI or Windows.UI.Xaml. A lot of them are very similar to WPF/Silverlight namespaces - e.g. Windows.UI.Xaml.Controls is closely matching System.Windows.Controls; ditto for Windows.UI.Xaml.Documents etc.
Now, .NET has the ability to directly reference WinRT components as if they were .NET assemblies. This works differently from COM Interop - you don't need any intermediate artifacts such as interop assemblies, you just /r a .winmd file, and all types and their members in its metadata become visible to you as if they were .NET objects. Note that WinRT libraries themselves are fully native (and so native C++ programs that use WinRT do not require CLR at all) - the magic to expose all that stuff as managed is inside the CLR itself, and is fairly low level. If you ildasm a .NET program that references a .winmd, you'll see that it actually looks like an extern assembly reference - there's no sleight of hand trickery such as type embedding there.
It's not a blunt mapping, either - CLR tries to adapt WinRT types to their equivalents, where possible. So e.g. GUIDs, dates and URIs become System.Guid, System.DateTime and System.Uri, respectively; WinRT collection interfaces such as IIterable<T> and IVector<T> become IEnumerable<T> and IList<T>; and so on. This goes both ways - if you have a .NET object that implements IEnumerable<T>, and pass it back to WinRT, it'll see it as IIterable<T>.
Ultimately, what this means is that your .NET Metro apps get access to a subset of the existing standard .NET libraries, and also to (native) WinRT libraries, some of which - particularly Windows.UI - look very similar to Silverlight, API-wise. You still have XAML to define your UI, and you still deal with the same basic concepts as in Silverlight - data bindings, resources, styles, templates etc. In many cases, it is possible to port a Silverlight app simply by using the new namespaces, and tweaking a few places in code where the API was adjusted.
WinRT itself doesn't have anything to do with HTML and CSS, and it bears relation to JavaScript only in a sense that it is also exposed there, similar to how it is done for .NET. You don't need to deal with HTML/CSS/JS when you use WinRT UI libraries in your .NET Metro app (well, I guess, if you really want to, you can host a WebView control...). All your .NET and Silverlight skills remain very much relevant in this programming model.
From the Build keynote:
They're providing common APIs to both HTML/CSS/JavaScript apps and C#/XAML apps. C# and XAML will be used, but it won't be WPF or Silverlight exactly.
The key idea is that now there is two development tracks - the Desktop and Metro.
The desktop is where the old apps live.
The new class of applications, Metro applications, can be built in a number of ways, including by VB.NET, C# or C++. These three language options can use XAML for building the UI. The alternative is to use JavaScript/HTML5/CSS for the development of both the UI and application code.
Some important points:
Windows 8 feels sort of like an upscaled mobile phone OS.
In Metro, there are no overlapping top-level windows, just as there are none on a mobile phone. If you want an MDI style application, you need to stay on the desktop.
Metro style apps are automatically suspended when not visible. This was done to prolong battery life. This means it won't make sense for many existing desktop apps, which perform background processing even while the user is not interacting with them, to be ported to Metro.
The ARM version of Windows 8 will not support desktop applications. So if you want to write an app and you want it to work on any version of Windows then it has to be a Metro app.
There's modified version of the architecture that'll surely help you understand where exactly the things lies. One of the Telerik ninjas had chat with the CLR team and modified the picture:
Here you can see where the CLR stands. The .NET framework now has two profiles
1- .NET Metro profile (CLR that deal with Metro application)
2- .NET Client profile (CLR runtime for C# and VB.NET applications)
I hope this gives you a clearer picture. Read the full article in A bad picture is worth a thousand long discussions..
Lots of detail from Microsoft here.
The Windows Runtime is exposed using API metadata (.winmd files). This is the same format used by the .NET framework (Ecma-335). The underlying binary contract makes it easy for you to access the Windows Runtime APIs directly in the development language of your choice. The shape and structure of the Windows Runtime APIs can be understood by both static languages such as C# and dynamic languages such as JavaScript. IntelliSense is available in JavaScript, C#, Visual Basic, and C++.
In short, Windows Runtime is a new set of libraries exposing Windows functionality and available to JavaScript/C#/VB/C++. Each language has been made to understand and be able to call them directly rather than having to go through some thunking layer.
Silverlight and WPF are flavors of XAML that run on the CLR. Among other functionality, Windows Runtime exposes a version of XAML very similar to Silverlight, but does so in a native way, not via the CLR. It can be accessed from the CLR, but also from C++.
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 4 years ago.
Improve this question
I'm in the early planning phase for a project and determining whether to use Silverlight or the Google Web Toolkit (GWT). There are obviously a lot of things to consider, but this question is specifically concerning deployment.
This application is intended for intranets; i.e. it is not a hosted website and is intended to be deployed at a customer's site. The target company size is small, so most would likely prefer to run on their pre-existing servers. The intent is not to sell the code base along with the application, so code security is a concern.
Given that:
Which is easiest to deploy?
Which is better for code security?
Which is better suited for deployment to the majority of small servers?
Both will work.
Both can be secured.
Neither place a heavy load on servers.
Use what makes more sense to the user. If I were using in Intranet application, I would probably want something that doesn't require me to download anything and runs smoothly in the browser. That makes me lean towards using the Google Web Toolkit (as long as you're comfortable with coding in Java).
If you think your users will be able to and ok with downloading Silverlight and you're a MS developer, go for it. The only downside is that your users have to download and install a runtime AND you might be using more internal bandwidth.
It mainly depends on what technologies you are familiar with. If you are a .Net shop, it just makes so much sense. Silverlight is compiled to XAP and is deployed on windows servers. Make sure you register the file extension of XAP in IIS. A XAP file is a Silverlight package that contains everything you need to deploy your Silverlight application, including the application manifest, the project assembly, and any other assemblies that your application uses
A major side effect of the Silverlight compilation model is the IL code can be easily decompiled or reverse engineered, Hence it is not an an appropriate place to store encryption keys, algorithms that are proprietary etc. If there is such needs, then design a web service that is on the server side. you can also try using obfuscation.
I would agree with what you are familiar with. Ask yourself, "What IDE am I best at?";
"What language do I know best, VB, C++, J#, C#, Java, ASP, JSP?".
What I know about either library would not give you much help but I have used them both.(just playing with samples).
I do know that GWT will take java classes and create a nocache.js file that your web page uses. I have not tried GWT with Silverlight although I did see this on the way here:
http://www.ongwt.com/post/2007/12/08/GWT-will-support-Silverlight
Is caching an issue? What classes does you system already support?
Both technologies are of an AJAX base. MS does it for Windows servers. Others use Open Source servers. What do use?
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.
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.