Moving From LINQpad to a Proper Visual Studio Project? - c#

I'm learning LINQ to SQL in LINQpad and it's been great, but there's a lot of magic happening under the hood that I don't quite understand. I am connecting to an Oracle database using the optional IQ driver that can be downloaded inside of LINQpad. I have my query working and now I need to move it into a new project within Visual Studio.
Is it possible to use IQ within my solution in Visual Studio? I can't seem to find any information about using it outside of LINQpad. I've attempted to use DbLinq's DbMetal tool to generate the proper connection class but something in my schema is choking the tool in a way that it did not for IQ.
Can the generated code for LINQpad be exported in some way? The generated Oracle connection code works perfectly in LINQpad - is there a way to just reuse that generated code?

Yes, it's technically possible to use the typed DataContext that LINQPad creates within your own VS solution. You can extract it by running a query such as this:
File.Copy (GetType().BaseType.Assembly.Location, ...
As Tom suggests, you'll also need to copy the supporting files in C:\ProgramData\LINQPad\Drivers\DataContext\4.0\IQDriver. Bear in mind that LINQPad uses the DevArt Oracle dotConnect as the ADO.NET backend for Oracle, for which you'll need to buy a commercial license in order to use in your own projects.
Another issue is that there's no way to customize the typed DataContext and this could prove limiting within the context of writing a VS solution (LINQPad generates the typed DC via Reflection.Emit and so there's no source code to tweak).
If you want to access Oracle databases via LINQ in a VS project, a better option might be buy DevArt's professional edition of dotConnect for Oracle which gives you an entire stack including an integrated VS designer for writing DataContexts (so you won't need IQ). The whole experience is very much like LINQ to SQL, but for Oracle (in fact, they've mimicked the API whereever possible which eliminates the learning curve). DevArt's LINQ translation engine has improved over the years and is now close to IQ's in translation ability (and better in some ways).

Yes, you can use the IQ (IQToolkit & IQToolkit-Oracle Provider) within your projects. You can get the dlls from your LINQPad install (C:\ProgramData\LINQPad\Drivers\DataContext\4.0\IQDriver*).
You will also want to use IQToolkit CodeGen tool to create your Entities and mappings.

As you know, Linq to SQL doesn't support Oracle natively.
A previous SO poster says "As of beta version 4.35, LINQPad supports Oracle fully - you can now do "LINQ to Oracle" queries. I believe it uses the DevArt dotConnect libraries for managing this great feat." [see https://stackoverflow.com/questions/1376132/linqpad-and-oracle/6821073#6821073]
which makes me think that if you want the same functionality outside of LinqPad your going to have to get the dev art oracle connector

Related

Generate EF stored proc methods from command line

I'm using EntityFramework 6 in VS2013 with database-first. When you pull in the database, you can get stored procedures, which builds methods into your context for each proc, as well as classes for each of the return types which it derives from the procedures.
I'm looking for a way to run this from the command line. The closest I can find is EdmGen, but this apparently does only tables.
I've seen EfGen, but aside from this just being a download from some guy with no source code or peer review, it appears to be at least one version behind.
Building the names and parameters of the methods is easy enough - I could do that myself with the SQL Server metadata - however, building the result classes would be tricker, so ideally I'd like to do whatever VS is doing.
Is there an SDK command or something I can pull from Visual Studio to do this on demand? I often have to re-pull my procs (early in the development process so things are constantly changing), and it's a hassle to do it in the UI.
I don't think what you are trying to do is possible from the command line. As you noticed in the EF6 Designer there is no public API for reverse engineering similar to the one exposed by EdmGen. The lack of the API is not actually the biggest problem here - in general models generated by EdmGen and the new designer are semantically the same - the only difference is that in EF6 two new provider manifest tokens were introduced for SqlServer - 2012 for Sql Server 2012 and 2012.Azure for Sql Azure. You will get these provider manifest tokens when targeting the above databases with the new designer but when using EdmGen you will get 2008. The actual problem here (and the reason why EdmGen does not support generating/importing store functions) is that in the EF provider model there is no way to get the description of the results returned by a store function. To make up for this the designer uses the DDEX provider which is able to return the description of the first result set (now, you also know why the EF Designer does not support stored procedures returning multiple resultsets even though it is supported by the runtime) returned by a store function. Since DDEX is basically a VS thing I don't think you will be able to import store functions from command line using out-of-the-box tooling.

Access Database Alternatives

Ok before I explain... I know Access should basically not be used anymore.
My application now uses access for its portability.. its an internal application and makes private/internal database storage a snap.
Problem is, it uses JET 4.0 which is not supported in 64 bit operating systems and is frankly not very well implemented anymore.
I am developing using C# .NET visual studio 2008. I am looking for a way to do this with some other database type that would not require me to install anything else on a users computer. I looked into sqlite but there's no easy way to implement it in visual studio
An Ideas?
You can use SQL Server Compact 3.5 (the embedded version of SQL Server 2008).
I recommend System.Data.Sqlite (http://sqlite.phxsoftware.com/), a managed, open-source ADO.Net wrapper around the open-source Sqlite database. No installation required - you just include the single DLL in your solution. It boasts a small footprint, encryption, and good performance.
SQL Server Express edition should come with Visual Studio. It is an option at installation time, IIRC.
Access has a couple of key characteristics:
- Single-user
- Requires installation
For alternatives this gives you (at least):
SQL Compact (doesn't require installation, single-user)
SQLite (doesn't require installation, single-user--although multi-user is supported)
SQL Express (multi-user, requires install)
SQL CE is a good option as already mentioned. You could also consider xml if the data is not private and you don't have concurrent users (which is very likely if you are using Access). Xpath provides a lot of the features you would normally need from database queries and storage. You also wouldn't need to install anything.
Did you try with H2?
The main features of H2 are:
Very fast, open source, JDBC API
Embedded and server modes; in-memory databases
Browser based Console application
Small footprint: around 1 MB jar file size
Check out about implementation:
http://www.google.ba/search?sourceid=chrome&ie=UTF-8&q=C%23+h2+database
This is one reason why people continue to use Access. Of course you want an easy solution that doesn't require any installs on the client side.
We've all assumed so far your users are disconnected from your SQL Server. If they can connect, you're home free. It's less of a problem if you need to support read-only disconnected use, more of a problem if you need to pull updated data from disconnected users.
Can you tell us more about what you need?
Firebird can be a very good alternative to Access and have very good dot net driver
Here is a comparison between Firebird Embedded and SQL Server Compact Edition
How about XML? Easy to use, and it works on any platform. Not the easies to implement if you're unfamiliar with it, but it's pretty rad once you learn how it works.

Easiest way to use SQL in a C# application?

I'm making an application in C# (with Express Edition) for which I would like to add some SQL functionality so that the user can query a database. I don't care how or where I store the database. I can store it in a DataTable or a bi-dimensional array or any kind of file. But I want the user to be able to SQL-query it. Apparently this should be quite simple since the .net seems to be full of database libraries and stuff. I was thinking about downloading MySQL and see if I can connect it to my application. I guess if I want to distribute my application then the user would need to download MySQL as well, which is not a big deal but would be great if I can avoid it. Anyway, for now I would like to start working on my program ASAP, so whatever is the easiest way to do what I want, even if it's not distributable, (but if it is then that's even better), will be good. Thanks in advance.
There are embeddable databases. SQL Server Compact Edition and SQLite are common ones. You can execute queries against these just as you can MySQL or SQL Server.
SQLite (.NET)
SQL Server Compact
You can use most popular databases with .NET. SQL Server, Oracle, MySQL, etc. But you're gonna need drivers of each. So, I'd suggest using SQL Server Express Edition to you to get started.
Then you can easily use SqlConnection and SqlCommand classes to connect and execute queries.
You could use a dbml file in your project and link it to your sql database and then run a sql statement using Linq2SQL documented here
I would look at using and embedded database that you can distribute with your application. SQLite is a very good option. You can then use a free ADO.Net library like System.Data.SQLite for data access. It also provides design time support for Visual Studio.
You can use LINQ to Objects or LINQ to Datasets to run LINQ queries with no database whatsoever. You can't use a bi-dimensional array, but you can use a List<> of objects with properties as a LINQ context.
From your question it sounds like your application, like most applications, may need to store the data for later use: that's where a database will come in handy. .NET Datasets have built in support for persistence to an XML file if your data storage requirements are simple enough to use that. .NET also supports persistence for objects, but you may find that using a database is the simplest solution, especially if you require multi-user access and editing.

Alternative to SQL Server for a simple web app

I have a simple app written using SQL Server, Entity Framework, C# and WCF. When I wanted to share this app with my friends, I realised they didn't use SQL Server on their machine. I could go for SQL Server Express edition, as the usage of my app is personal and non-commercial.
I found MySQL as a popular alternative to SQL Server.
1) Would I be required to update my entities when moving to MySQL?
2) Should I anticipate code changes in my BL layer due to change in entities layer? (I am wondering whether entities was built for SQL Server)
Are there any databases similar to MS Access that is lightweight compared to MySQL?
Are there any databases that need not be installed but can be copied around like MS Access?
Appreciate your response!
Sounds like you want SQLite.
SQLite is a software library that
implements a self-contained,
serverless, zero-configuration,
transactional SQL database engine.
Very easy to deploy. Also, check out System.Data.SQLite.
According to the System.Data.SQLite page ...
Supports nearly all the entity
framework functionality that Sql
Server supports, and passes 99% of the
tests in MS's EFQuerySamples demo
application.
You should be good. :)
Im not sure how your BLL looks like and i have no experience with entity framework, but ive experienced multiple times that linq-to-sql works much better with sql-server as with any other database.
So unless you have a good reason not to use sql express, i'd advice to stick to sql express.
After all, you should always install something when deploying (unless you use xml as storage, which is quite well possible with linq-to-xml).
VistaDB Express Edition is also free for non-commercial usage and integrates good into .NET and VS. afaik it also works on a single local data file thus requires no specific installation on your friends' computers.
Otherwise I recommend using PostgreSQL over MySql since it is more standards compliant and has a nicer license.
I think what you're after is just a change in providers. What you need to use MySQL is the .Net Connector which supports most everything simple. It's not very mature yet so something very complex you may have issues on, but it should do most of what you want through Entity Framework.
With Entity Framework yes you can do updates, it's LINQ-to-SQL that doesn't update against any other databases (unless you use a third party provider like DotConnect)
SQLite is one alternative, but since multiple threads against it can cause major issues with it's operation, so if you need a major data store I'd go SQLExpress or MySQL.
Yes, you could use MySql with EF but I don't know if it would require changes.... I wouldn't be surprised if it does though. At the very least your physical DB would have to be ported / converted to MySql and that will take time.
I would assume that if you need to install a DB on your friends Pc's why not stick with SQL Express since you already developed in SQL Server on your box. Should be less issues with this than migrating to MySql.
I'd also vote for VistaDB 3 as it's so easy to deploy.

How can I use Linq with a MySql database on Mono?

There are numerous libraries providing Linq capabilities to C# code interacting with a MySql database. Which one of them is the most stable and usable on Mono?
Background (mostly irrelevant): I have a simple C# (.Net 2.0) program updating values in a MySql database. It is executed nightly via a cron job and runs on a Pentium 3 450Mhz, Linux + Mono. I want to rewrite it using Linq (.Net 3.5) mostly as an exercise (I have not yet used Linq).
The only (free) linq provider for MySql is DbLinq, and I believe it is a long way from production-ready.
There is also MyDirect.Net which is commercial, but I have heard mixed reviews of it's capability.
I've read that MySql will be implementing the Linq to Entities API for the 5.3 version of the .net connector, but I don't know if there's even a timeline for that. In fact, MySql has been totally silent about Entity Framework support for months.
Addendum: The latest release of the MySql Connector/Net 6.0 has support for the EF according to the release notes. I have no idea how stable/useful this is, so I'd love to hear from anybody who have tried it.
According to the Mono roadmap I'm not sure if Linq is available for mono?
At least some of Linq might be available in the very latest release, but Linq to DB is listed for Mono 2.4 (Feb 2009)
Not sure about Mono, but I just started using LightSpeed and that supports LINQ-to-MySQL.
at this time you cannot use linq to sql, you might look into a third party linq mysql provider or linq to entities. linq to sql only works for sql server databases.
LINQ to SQL is simply a ORM layer leveraging the power of expressions to make it easy to construct queries in your code.
If you are just calling adhoc queries for your tool, there is little need to use LINQ, it just adds an extra layer of abstraction to your code.
I have tried the tutorial at http://www.primaryobjects.com/CMS/Article100.aspx. This uses dblinq/dbmetal to generate the data context class and classes for each table.
The code failed at the first attempt with an unhandled exception (MySql.Data.Types.MySqlConversionException: Unable to convert MySQL date/time value to System.DateTime"). Googling revealed this should be easily solved by appending "Allow Zero Datetime=True;" to the connection string.
Unfortionately this turned out not to solve my problem. Thinking the MySQL .Net Connector was to blame I executed the SQL generated by dblinq without the linq2sql intermediary layer using the MySQL Connector. This time no exception occured.
Tables which do not have a date column did work with DbLinq.
So, from my experiment I agree with Adam, DbLinq is a long way from production ready.

Categories

Resources