Web Application Structure and Deployment

后端 未结 4 727
伪装坚强ぢ
伪装坚强ぢ 2021-02-14 04:47

Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time.

相关标签:
4条回答
  • 2021-02-14 04:54

    By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.

    If am right you can Add this WebResource in your base project then go through the below link.

    http://support.microsoft.com/kb/910442

    Like this way, most of the third party tools will access their CSS and JS files.

    Try this. Hope it will help.

    0 讨论(0)
  • 2021-02-14 05:09

    If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).

    So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).

    I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.

    0 讨论(0)
  • 2021-02-14 05:10

    How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.

    0 讨论(0)
  • I would carefully analyze what you are sharing between projects and how you share them.

    If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.

    If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.

    On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.

    Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders). I would suggest sticking to the 2 step deployment process with Web site projects.

    I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.

    Lastly, this is an old question. Please share if you have already implemented a successful strategy.

    0 讨论(0)
提交回复
热议问题