Data Access guidance package with Web Application???

Topics: General Discussion Forum
Jun 14, 2007 at 4:15 PM
Edited Jun 14, 2007 at 4:20 PM
Hi,

I'm trying a bit different thing with the data access guidance package. I liked the way repository pattern worked in web service software factory. So I decided to try it with a web application. So I loaded a web application. Loaded data access guidance package. Assigned web application project as Host project. Assigned BE and data access projects. Added database connection string. Everything went smooth. Now when I try to create CRUD Sps it just doesn't bring up the connection strings. It, however, preselects the host project in the recipe. Am I missing something? Any ideas if I can make use of data access guidance package with web applications?

Cheers,

A.
Jun 14, 2007 at 11:35 PM
Check that you have a valid connections string section in your web.config file.
A typical sample will be like this:

<connectionStrings>
     <add name="Test" connectionString="Data Source=D620\SQLEXPRESS;Initial Catalog=CohoWinery;Integrated Security=True"
 		  providerName="System.Data.SqlClient" />
</connectionStrings>
For some reason (bad format, missing section, etc) the recipe is not getting this section and therefore you are not seeing any value to select.
Jun 15, 2007 at 9:07 AM
Thanks for your reply. The connection string's there. In fact it did add it itself. I tried creating a blank web application with simple stuff and the web.config is as clean as anything. When you run the add connection recipe it works but when you try to run create CRUD recipe it never picks it up. I'd appreciate any help.

Cheers,

A.

charlyfriend wrote:
Check that you have a valid connections string section in your web.config file.
A typical sample will be like this:

<connectionStrings>
     <add name="Test" connectionString="Data Source=D620\SQLEXPRESS;Initial Catalog=CohoWinery;Integrated Security=True"
 		  providerName="System.Data.SqlClient" />
</connectionStrings>
For some reason (bad format, missing section, etc) the recipe is not getting this section and therefore you are not seeing any value to select.


Jun 15, 2007 at 9:30 AM
I even tried replacing the web.config of a webservice that DOES show the connections. So far I don't see any reason why we shouldn't be able to use Data Access guidance (Web Service Software Factory) in a web application. Moreover I don't see ppl taking any interest in this topic. I wonder why???

Avy wrote:
Thanks for your reply. The connection string's there. In fact it did add it itself. I tried creating a blank web application with simple stuff and the web.config is as clean as anything. When you run the add connection recipe it works but when you try to run create CRUD recipe it never picks it up. I'd appreciate any help.

Cheers,

A.

charlyfriend wrote:
Check that you have a valid connections string section in your web.config file.
A typical sample will be like this:

<connectionStrings>
     <add name="Test" connectionString="Data Source=D620\SQLEXPRESS;Initial Catalog=CohoWinery;Integrated Security=True"
 		  providerName="System.Data.SqlClient" />
</connectionStrings>
For some reason (bad format, missing section, etc) the recipe is not getting this section and therefore you are not seeing any value to select.



Jun 15, 2007 at 3:30 PM
Edited Jun 15, 2007 at 3:31 PM
Ok, I've moved a bit further on this. It's to do with Web Application Projects. If I create a new Web Site Project and try and use the data access guidance package with it, it works perfectly fine. I looked at Web Application Project and found out that it has some known issues with connection string in the web.config file. So far I couldn't find a work around but if anyone of you knows about it please do let me know. Would appreciate that.

Cheers,

A.
Jun 15, 2007 at 7:19 PM
I'm. afraid that "Web Applications" are not supported by WSSF. You should use a "Web Site" project instead.
You will also notice that a web project only allows you to set its responsability as a Host project, so you should set the rest of the responsabilities in a separate assembly (or assemblies).
Thay way it should work fine.
Regarding you last concern, I don't know what is ppl but the "Web Application" constrain is by design.
Jun 18, 2007 at 9:22 AM
Thanks for your reply charlyfriend. That sounds like a convincing statement but I wonder why would anyone wanna restrict a feature that was provided not just for backward compatability but to let developer organize their webapplication projects as they want it. Anyway, I guess another website project has to come into my solution.

Oh yea about ppl I meant people. Anyway, thanks again for your help. saved another day of my research.

Cheers,

A.


charlyfriend wrote:
I'm. afraid that "Web Applications" are not supported by WSSF. You should use a "Web Site" project instead.
You will also notice that a web project only allows you to set its responsability as a Host project, so you should set the rest of the responsabilities in a separate assembly (or assemblies).
Thay way it should work fine.
Regarding you last concern, I don't know what is ppl but the "Web Application" constrain is by design.

Jun 18, 2007 at 9:40 AM
Hey,

I just got a wicked idea. How about adding a new website project in the solution (Not moving anything from webapplication project to website project). Set the project's responsibility as Host. Add the database connection in the website project and that's it. Now you can run your data access recipes for generating stored procedures, repository classes, and business entities etc. Once done you can throw away your website project as you only needed it for generating those classes. And I don't believe the runtime knows what WSSF is. I've not tried it yet. Just gonna try it. Will post my results here. Good hack isn't it? Let me know of your thoughts on this.

Cheers,

A.

Avy wrote:
Thanks for your reply charlyfriend. That sounds like a convincing statement but I wonder why would anyone wanna restrict a feature that was provided not just for backward compatability but to let developer organize their webapplication projects as they want it. Anyway, I guess another website project has to come into my solution.

Oh yea about ppl I meant people. Anyway, thanks again for your help. saved another day of my research.

Cheers,

A.


charlyfriend wrote:
I'm. afraid that "Web Applications" are not supported by WSSF. You should use a "Web Site" project instead.
You will also notice that a web project only allows you to set its responsability as a Host project, so you should set the rest of the responsabilities in a separate assembly (or assemblies).
Thay way it should work fine.
Regarding you last concern, I don't know what is ppl but the "Web Application" constrain is by design.


Jun 19, 2007 at 3:42 PM
Sounds fine to me. However, I wonder why you cannot simply create all the classes in a separate library project so you may reuse it from a web site or web application and you won't need to move/remove anything. All the required recipes may be enabled (resp. available) from a library project and it will only require a reference from your web project.
Let me know if I'm missing somthing but I think this will be the most simple and best alligned with WSSF approach.
Jun 20, 2007 at 2:43 PM
Yes, that did work. But I didn't quite catch you there. All the repository classes are already generated in a separate assembly. BEs stay in a separate project as I want them there due to architectural restrictions. I don't know what exactly is your point in saying "create all the classes in a separate library project".

Cheers,

A.

charlyfriend wrote:
Sounds fine to me. However, I wonder why you cannot simply create all the classes in a separate library project so you may reuse it from a web site or web application and you won't need to move/remove anything. All the required recipes may be enabled (resp. available) from a library project and it will only require a reference from your web project.
Let me know if I'm missing somthing but I think this will be the most simple and best alligned with WSSF approach.

Jun 20, 2007 at 5:43 PM
Ok, got it. Then your solution/workarround should be fine.

Cheers,
Charly