0

I have a .NET 3.5 web application that I recently added some Linq to Sql functionality to -- a dbml file, etc. Locally, it works fine.

However, when I try to deploy it, I get a null reference exception, apparently when it's trying to call the constructor for the context object.

To add to the complexity, I use a Web Deployment Project which compiles it into a single DLL. I assumed the Linq to Sql stuff would get compiled along with everything else. However, now I'm thinking that I need to move the dbml file up along with the DLL.

I had the dbml file in the App_Code directory, so I tried recreating that directory structure on the remote server. But .NET will not let me have an App_Code directory on a precompiled application. So I just moved the dbml file into the root directory -- but I still get the error.

Help!

Here's the stack trace for the error I'm getting:

[NullReferenceException: Object reference not set to an instance of an object.] codeCS.SarcStateDataDataContext..ctor() +28 DB_Interface.SarcStateDataDB..ctor() +26 eSARC_Basic..ctor() +56 ASP.esarc_basic_aspx..ctor() +14 __ASP.FastObjectFactory_sarcwriting.Create_ASP_esarc_basic_aspx() +20 System.Web.Compilation.BuildResultCompiledType.CreateInstance() +32 System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert) +119 System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +33 System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +40 System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) +160 System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +93 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +155

DB_Interface.SarcStateDataDB is a class I wrote that calls the constructor for the context object:

codeCS.SarcStateDataDataContext context = new SarcStateDataDataContext();

I don't send it a connection string or connection object, because both the local and deployed versions of the program use the same remote database. But could that be the problem? The local application has access to the connection string in the dbml file, but the deployed application doesn't ... ??

UPDATE: I looked at the code in Reflector and it is getting the connection string from the web.config, and everything looks copasetic on that issue ...

Cynthia
  • 2,100
  • 5
  • 34
  • 48

3 Answers3

2

OK, I found the problem! The connection string name it was looking for -- SarcWritingConnectionString -- was something that apparently Linq to Sql had added to the web.config when I was setting it up initially, going through the wizard. And I did not move up the new web.config to the server when I deployed the project, because I thought that it had not changed. When I move it up, everything works!

(I used a data connection I had already set up in Server Explorer instead of a connection string that was already in the web.config -- I wasn't even sure how to do that.)

Thanks for your help -- it's good to know I don't need to move up the dbml file. Next time will be easier!

Cynthia
  • 2,100
  • 5
  • 34
  • 48
1

Hi Cynthia You don't need to deploy .dbml file. The null reference exception is not caused by the lack of .dbml. It's hard to guess the problem with the provided information, but first of all check that the data on the production and development database are the same. Maybe the production database lacks some records and you get nullreference from there. Also make sure that you deploy the project using VS Publishing Wizard (Right click on the project -> Publish). Also, if this doesn't help, could you post a stack trace of the exception? Thanks

Davita
  • 8,928
  • 14
  • 67
  • 119
  • THanks Davita -- I have updated my post with some more information. Since both development and production databases are the same, I don't think that's the problem. – Cynthia Dec 02 '10 at 18:14
1

I'd suggest that you pass DB_Interface.SarcStateDataDB the connection string you want to use when you instantiate the class, then use that in its codeCS.SarcStateDataDataContext context = new SarcStateDataDataContext();.

Then you can manage the connection string at the application level, presumably in your web.config file. This way if you ever switch to using a dev db that is separate from prod, then you easily transition to separate connection strings.

mlibby
  • 6,567
  • 1
  • 32
  • 41