The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.

Hi John;

Did you also move the app.config file along with the executable?

While creating the EF model through wizard, at the end will ask you whether you wish to keep the connectionstring in App.config (Windows) / Web.config( Web application) in redable format with credentials.

So, if you one you development applications App.config file, you can notice the connection string and thus include the same with the final executable package.

Fernando,

No, I have not moved the app.config file, can't that somehow be bundled for a Form App

Santhimurthyd,

I wasn't able to follow you.  I know what you are talking about in regard to the wizard and how it mentions the App.Config.  If I were to choose, No, I'm not sure how to adjust the properties and the App.config to accommodate this connection

Hi John;

If you mean by bundled that the app.config file is embedded into the apps executable no, if you mean that when deployed the app.config file is included in the deployment then yes.

So I could simply copy and paste it into the same directory?  How is the deployment accomplished so that I don't have this problem?

Thanks!

To your question, "So I could simply copy and paste it into the same directory?", yes, you can copy it in to the same directory you copied the exe file into.

There are many ways to deploy an application simplest is just to copy the needed files to the location you want to use it in. Then you have deployment project that you add and you create the needed tasks to deploy your application. You have Click Once and other third party applications.

Of all you mentioned above in the last comment, can you demonstrate how I would use the approach below.  I'm pretty sure these two dialogs would provide one method, right?  That is, the answers I provide for the EDMX configuration will have an impact on using the project properties.

I'd like to know how I can use the project properties to set the credentials and use them that way.  I don't want to copy the AppConfig file and I have 'no' other dependencies that need to go with this.

In the end, what ever works using a deployment wizard etc:

project-properties.jpg

John

After creation of the EDMX file, you will be able ot see an edmx.cs file which will have the instance to get the connection string in the constructors, You can over ride the same from application settings.
Check below blogs

http://stackoverflow.com/questions/4153650/entity-framework-4-is-it-possible-to-read-a-connection-string-from-another-file

http://msdn.microsoft.com/en-us/library/bb739017.aspx

Ok great, let me take a look at them !

So you agree the second article is suggesting this code should go within Form1 during initialization like:

public Form1()
{
    InitializeComponent();

// Create the ObjectContext.
ObjectContext context =
    new ObjectContext("name=AdventureWorksEntities");

// Set the DefaultContainerName for the ObjectContext. 
// When DefaultContainerName is set, the Entity Framework only 
// searches for the type in the specified container.  
// Note that if a type is defined only once in the metadata workspace 
// you do not have to set the DefaultContainerName.
context.DefaultContainerName = "AdventureWorksEntities";

ObjectSet<Product> query = context.CreateObjectSet<Product>();

// Iterate through the collection of Products. 
foreach (Product result in query)
    Console.WriteLine("Product Name: {0}", result.Name);

Select allOpen in new window

}

Ok, terrific.  I have to take a look on Monday.

So you agree there is something about the way the EF Wizard produces the connection that is problematic, right?  What am I missing exactly?

Thanks!

Hi John;

To your question, "So you agree there is something about the way the EF Wizard produces the connection that is problematic, right?",  no I would not agree with that, it is not a problem or difficult it is just how it was implemented. You can choose to have the connection string stored in the app.config file or you can supply the connection string and in order to do that you have to create a partial class to overload the default constructor.

Fernando,

I posted the other question yesterday because I wanted as much feed-back on how to deploy an EF related executable.  Thank you for your help on both.

As I mentioned above, I have to wait until Monday to move in the direction you have provided.  I still have two questions that I'm not 100 % clear on.  Regarding the EF dependency, I know this is a dependency but you admit not all dependencies require a separate dll for deployment?  I was thinking - whatever EF needs it will bundle it up in the Release build.  To this you say -" incorrect, you will have to have the EntityFramework.dll in the same directory as the executable", right?

The second question deals with Entity Framework 5 and using DbContext.  I'm still too new to this but will soon understand.  Unfortunately, we are only using VS 2008 and .NET 3.5.  If I understand correctly, this means I have Entity Framework 4 and can download 4.1 if it isn't already on there.  I don't know if .NET 3.5 supports EF 5.

How does this impact things?  Also, can you briefly explain what "DbContext" and "code first" means here to you?  I know that DbContext is an object but I'm not sure what it signifies until I do further reading.

As always, thank you!

John;
 
To your question, "Regarding the EF dependency, I know this is a dependency but you admit not all dependencies require a separate dll for deployment?", all API's that you use in your code require a separate dll for deployment. Whether they get installed on the target machine will be dependent on if they were previously loaded to the system. So in a deployment package you will have EntityFramework.dll but it may not be installed because it was previously loaded on the system.
 
To your question, "I was thinking - whatever EF needs it will bundle it up in the Release build.  To this you say -" incorrect, you will have to have the EntityFramework.dll in the same directory as the executable", right?", no, when you execute a program it looks for the dependent DLLs In a couple of locations. The following list the locations it looks for them.
 
The directory where the executable module for the current process is located.
The current directory.
The Windows system directory.
The Windows directory.
The directories listed in the PATH environment variable

And if it is a shared DLL such as EntityFramework.dll it also looks in the GAC, Global Assembly Cache.

To your question, "Unfortunately, we are only using VS 2008 and .NET 3.5.  If I understand correctly, this means I have Entity Framework 4 and can download 4.1 if it isn't already on there.  I don't know if .NET 3.5 supports EF 5.", well .Net 3.5 was a while back for me. If I remember correctly EF 4 requires .Net 4.0 and EF 5 can use .Net 4 and 4.1 but all function in EF 5 are not supported.

To your question, "How does this impact things?  Also, can you briefly explain what "DbContext" and "code first" means here to you?  I know that DbContext is an object but I'm not sure what it signifies until I do further reading.", Well running on .Net 3.5 will not allow you to run the newer versions of EF. DbContext is a lightweight version of ObjectContext class. Code First is a process of building a model in code and then build your database from that code / model. Both DbContext and Code First are only supported from EF 4.1 and up.

That's a lot to swallow.  I'm hoping I can get 4.1 with .NET 3.5.  

Let me ask - do you feel the client could ever limit software solutions - say in the case of the .NET Framework.  

That is - is there any reason why the client (a government facility or large company) would have to avoid a upgrading to a certain .NET Framework version?  The Frameworks are all backward compatible, right?  

In a worse case scenario, could XP take .NET 4.0 Frame Work or greater?  Any OS after that should certainly be able, right?

Hi John;

To your statement, "I'm hoping I can get 4.1 with .NET 3.5.",

ADO.NET Entity Framework 4.1
System Requirements

Supported Operating System
Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP
Supported Architectures: x86; x64

ADO.NET Entity Framework 4.1 requires .NET Framework 4.0 RTM to be installed.

To your questions, "is there any reason why the client (a government facility or large company) would have to avoid a upgrading to a certain .NET Framework version?  The Frameworks are all backward compatible, right?  ", Frameworks are all backward compatible but is not the only reason why an institution may not want to upgrade such as "let them get all the bugs out before I install it on my system".

To your question, "In a worse case scenario, could XP take .NET 4.0 Frame Work or greater?  Any OS after that should certainly be able, right?", Please see the above system requirements for an answer to this question.

>>  I am going to assume that you are using Entity Framework 5 and using DbContext.

I'm going to find out whether downloading VS 2010 Express and extending it for 6 months is possible.  If so I'll go that route using EF 4.1

>> So in a deployment package you will have EntityFramework.dll...

We have one particular directory for running all applications.  Does the EF dll reside in the application's directory or is there some particular directory it should be installed?  

Thanks!

To your question, "We have one particular directory for running all applications.  Does the EF dll reside in the application's directory or is there some particular directory it should be installed? ", because EF is used by different software packages and different programs that you write the better place for it is in the GAC as I stated in a previous post.

I've requested that this question be closed as follows:

Accepted answer: 0 points for John500's comment #a39378005

for the following reason:

Thanks for all the info on that one.

I have answered the question with a working solution as well as follow up questions. The other question had to do with application deployment. I feel that the post should be awarded points

Fernando,

Trust me when I say - I closed this question and awarded you all the points for this comment ID:

ID: 39378224

I can not explain what happen outside of an EE glitch.  My last comment - "Thanks for all the info on that one" was the only thing that accompanied my action.  All I can say is either an EE glitch occurred or possibly the lap-top I'm using shifted the cursor (as sometimes happens) without me realizing what the heck took place.

You have great patience and tact considering this malfunction whatever it was.

Thanks again for help!!

Not a problem John, I figured it was something like that thank you.

Ok Modulas_Twelve, thanks.

Fernando,

I scrapped the idea of using .NET 3.5 with EF v1.  Having said that, you might be interested in this one:

https://www.experts-exchange.com/questions/28204362/Typical-class-for-data-access-how-to.html