I am having some refactor troubles, maybe someone knows why...
In one solution I have a WCF service. In another solution I have a RIA application. Since the SQL database between these two is identical, I wanted to create a separate project, in which to host the edmx file as well as a domain service. If I create the edmx file in the WCF project directly, and do the same on the RIA side, everything works fine.
But when I try to pull this edmx file into a separate project and add references to it I get all kinds of bizarre errors that my entity objects cannot be found. The WCF service itself seems fine, in that it references the edmx project and compiles just fine.
But the WCF client project, that has a service reference to the WCF service pukes on the entity references. Even adding the edmx assembly doesnt really help- some entities are found others are not. Very odd.
Anyone know what Im missing?
Copy the connection string across all your projects which attempt to use the model.
However, in the connection string, remove the OR'd Resource pointers.
e.g. Full Entity Connection
<connectionStrings>
<add name="AwesomeEntityModel"
connectionString="metadata=res://*/AwesomeEntityModel.csdl|res://*/AwesomeEntityModel.ssdl|res://*/AwesomeEntityModel.msl;provider=System.Data.SqlClient;provider connection string="data source=.\sqlexpress;initial catalog=NEILHIGHLEY.COM;integrated security=True;multipleactiveresultsets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
</connectionStrings>
Trim it to the following;
<connectionStrings>
<add name="AwesomeEntityModel"
connectionString="metadata=res://*;provider=System.Data.SqlClient;provider connection string="data source=.\sqlexpress;initial catalog=NEILHIGHLEY.COM;integrated security=True;multipleactiveresultsets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
</connectionStrings>
Based on what you've posted so far and taking it that you've ensured that the "edmx" project has a new namespace that is also used by the other projects.
If I'm reading what you've said correctly:
your WCF server references the "edmx"
project.
your WCF client references the WCF
server AND the "edmx" project.
It could be something as simple as circular referencing conflicts. Make sure that any "edmx" reference data within both of the other projects aren't public, just in case the client is picking up "edmx" data from the server project.
Also check whether missing items are left at the default accessibility of internal (when not defined).
Related
I am new to ADO.NET, I am using MYSQL with WCF.
I have a WCF project with ADO.NET, the SalesSolLIB project has reference of SalesSolWCF, and SalesSolView has reference of SalesSolLib project.
The problem is ADO.Net entities are created in WCF and when run, the error comes as although the name is present in web.config file.
"No connection string named 'SalesSolEntities' could be found in the application config file."
WebConfig File
<connectionStrings>
<add name="SalesSolEntities" connectionString="metadata=res://*/SalesSolDBModel.csdl|res://*/SalesSolDBModel.ssdl|res://*/SalesSolDBModel.msl;provider=MySql.Data.MySqlClient;provider connection string="server=localhost;user id=root;password=surpavan;persist security info=True;database=salessol;old guids=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
Code in WCF file:
Dim DB As New SalesSolEntities()
DB.Database.Connection.Open()
DB.Database.Connection.Close()
Return "test"
Code in SalesSolLib:
Dim service As New SalesSolWCF.ContactService
Dim errormsg As String = service.SaveContact(wcfcontact, IsNewContact)
However, through browsing, I found that connection string must be all the projects, however, why would I need to use WCF if connection string is needed in all projects, please advice how this can be solved, I don't want to put connection string in all projects or did I do wrong?
I am using Entity Framework 5.0 and the WCF Service Application as wcf project type.
You are calling your WCF services the wrong way. You do not add the reference by simply adding reference to DLL, you need to expose WCF endpoints via MEX, and then add reference by using "Add Service Reference".
What you've done now is that you're using your WCF not as a a service but just as a simple class that you make an instance off and then call it's methods. That is not how WCF services should be used, and that is why you get "connection string" missing error. Method in your class talks to database, so when you create instance of that class in other project, and call that method, that project must also have matching connection string. Basically it is all wrong, should not be done this way.
WCF services must be hosted either as self-hosted in your application or within IIS. I'd suggest that you go and take some basic WCF tutorial, otherwise what I just wrote will not make much of a sense to you.
I'm building an web api using ASP.NET web api framework. I have seen a few tutorials on how to get started but I haven't found to use an existing SQL Server database. I have the database up and running also added the data connection to the database explorer in VS but I don't know how to connect the database to my project so I can start using it as my repository. How can I do that?
Put the following in your application web.config file and replace "yourConnectionString" with the actual connection string.
<configuration>
<connectionStrings>
<add name="DbConnection" connectionString="yourConnectionString" />
</connectionStrings>
</configuration>
In the code use System.Configuration.ConfigurationManager.ConnectionStrings["DbConnection"].ConnectionString to get its value. You might need to reference the "System.Configuration" assembly in your project.
I've just upgraded a .NET 3.5 MVC 1 project to .NET 4.0 MVC 3 and for some reason now when I try to run it it says:
The connection name 'LocalSqlServer' was not found in the applications
configuration or the connection string is empty.`
I'm not sure why it does this as no where in my code does it look for a LocalSqlServer connection string, and if I put in a LocalSqlServer connection string in my config file with the value of my standard connection string and try to go onto the website, it takes me to the 'please log in' URL but with a 404 page (and not the custom 404 page either)
Anyone know what the problem could be?
Regards,
Harry
The LocalSqlServer connection string is defined in your Machine.config.
If you don't have a default Machine.config file, it might have been removed. You would then need to re-add it inside your own Web.config.
My LocalSqlServer:
<add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient"/>
You can find your machine.config here:
C:\Windows\Microsoft.NET\Framework\[FRAMEWORK VERSION]\CONFIG\machine.config
I have been tracking this same issue on a local application. When I had started working on it, the application was running ASP.NET Framework version 4.5. In the past, it had implemented structures from namespace System.Web.Providers. We updated the code to no longer use these classes and removed their references in the Web.config but we still received this error.
What I determined was the System.Web.Providers.dll was still present within the bin directory. We removed the reference before we performed a Clean or Rebuild, so the Clean or Rebuild action never removed it. (Note: It also never cleaned other files from references we removed before the Clean/Rebuild.) After deleting the files from the corresponding application bin directory, the application no longer threw the exception related to LocalSqlServer.
I am creating solution and inside I have three projects:
A WCF Service Library Project
A DataAccess Project (Class Library)
A Web site for hosting WCF service
The implementation of the service is on the project # 1, but in order to access the DataBase I use a second project that implements the data access using a class library project.
That problem is in order to get data access I need to configure a connection string, but that connection string must be configurable in a production environment, I meant in production I am going to deploy the site, which is a very simple project that contains only a reference WCF Service Library Project then a guy from database department will configure the connection string.
In development I have an app.config on the data access project but when I do the release that app.config is embedded on the dll.
Any ideas how can we achieve our purpose
The connection string must be in the application configuration file of the executing assembly. This means that you can provided the configuration file for your assembly along with the assembly itself but anyone who wants to use your assembly must update their configuration file to include the values that your assembly relies on.
The connection string in your app.config (data layer) is not embedded in the dll.
If you look in the app.config file in your data layer project, you will probably have a connectionStrings section. you need to put the connectionStrings in the web.config of your WCF service website.
This can be configured in your production environment.
I had a mistake, I was using a different name on the web.config of the WCF site, I just copy the the exact part of the app.config to the web.config and its working now.
Thanks for your help
It seems the world is awash with people having problems deploying RIA WCF services, and now I'm one too. I've already tried a bunch of things, but to no avail. I need WCF RIA to support a Silverlight 3 application I've built.
The short story is, using the new WCF RIA services (Nov 09?) I open VS 2008, create new project (silverlight application), enabling ".NET RIA services". Add new item to web project - Linq2SQL dbml file (from SQL 2005 DB prepared earlier) and compile. I add a new item to the web project - domain service (link the tables I need) and compiled. Using the domain context I "Load" data with a standard RIA get query in the MainPage and add a TextBlock to display returned data. Build & run (cassini) - success. Using VS to publish to IIS on local PC - success.
Using VS to publish to test server (IIS6) - browse to location and the Silverlight app loads but Fiddler tells me I've got a 404 on all the the WCF .svc requests. Use Fiddler to "launch IE" on the service request and it's true - 404.
I have already run aspnet_regiis, ServiceModelReg and added mime types for .xap, .xaml, .xbap and .svc. I have included the System.Web.Ria and System.Web.DomainServices DLL with copy local true.
I need help with either
a) a solution
b) an approach to find a solution
I had some troubles with this also, although once I figured them out it's relatively straight forward.
First, run through http://timheuer.com/blog/archive/2009/12/10/tips-to-deploy-ria-services-troubleshoot.aspx (although it seems you have most of that covered off).
Check that you have your DomainServiceModule in the web.config in the new system.webServer bit and the old bit for IIS6:
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="DomainServiceModule" type="System.Web.Ria.Services.DomainServiceHttpModule, System.Web.Ria, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</httpModules>
Finally, I had to create my services manually, by creating .svc files where SL is looking for them (from fiddler) and filling them in with:
<%# ServiceHost Service="NameOfSerice" Factory="System.Web.Ria.DomainServiceHostFactoryEx" %>
Make sure that you also visit the .svc file directly (without the /binary on the end) as you can get some nice errors there (well once you solve your 404 of course!)
HTH,
Jordan.
I fought this issue for a little while myself where it could not find the .svc file. I soon realized it wasn't just my .svc, it was all .svc files. It then appeared to be an IIS6 issue. It turns out that the ASP.NET v4.0x Web Service Extensions are set to "Prohibited" by default. Went into Web Service Extensions config and set ASP.NET v4.0x to "Allowed" and life was all good.
I ran into the same problem. Worked fine with the cassini server under Windows 7. Deployed to Windows Server 2008 R2 with IIS7, and it would not work. Fiddler reported that an 'EndPointNotFoundException' was being thrown.
My solution, since I have full control of the server, was to install Visual Studio 2008 Express, Silverlight 3 SDK, and the WCF RIA Services Beta for VS2008. This meant that the necessary DLLs were already installed in the GAC. I don't think this affected the result, but I turned off 'Copy Local' for the RIA DLLs that were referenced by the Web app.
Probably an unorthodox solution, but it worked for me!!! Actually, I did this at the suggestion of Microsoft Support.
By the way, support for this through Microsoft is very sparse at this time. They are actually trying to figure out right now internally who is going to support this technology: WCF team or Silverlight team. I know it's still in beta, but be warned that a 'GoLive' license doesn't mean its fully supported. I had someone from the WCF team who went out of his way to help me on this, but gave me a disclaimer several times during the call, that it wasn't really supported through those channels yet.
If someone is interested, how to deploy a complete Silverlight solution to IIS with your own batch script, read my answer in this post:
Is there a Management Service (WMSVC) UI in IIS 7 on Windows 7?
I did this, because there was no way, the in-bulit webdeploy feature of VS 2010 was working. The batch script makes it possible, that you can run and debug on IIS.
I know, this is not the explicit answer to this question, but it is a very similar question.
I think you would only use FactoryEx if you extended the Factory as described here. Also, according to my help files, the full name is System.Web.Ria.Services.DomainServiceHostFactory, but the parser can't create that type either, although I have System.Web.Ria in the GAC.
I agree - deploying WCF RIA over https is a challenge - I have yet to get it to work.