We are working on an ASP.NET MVC 3 project and taking advantage of Razor syntax to resolve paths and what not.
We are also employing a UI design team who is responsible for maintaining the design of our pages through the use of CSS and modifying the HTML in the cshtml pages.
The problem is, they work exclusively on Mac laptops without access to a web server or a .NET IDE.
Initially, they were just providing us a straight .html file along with a .css file and we were manually merging in their work into our ASP.NET solution (e.g., replacing paths with Razor markup, etc), but as the project grows and we become more involved, we are looking for a solution that will save us from these manual merges.
I was thinking I could create some kind include script that would rewrite the paths depending on whether the UI designers were editing the file, or the .NET devs, but this seems archaic.
Anyone out there been in this situation before?
Razor is a templating language, and a pretty small one at that. Could your UI team familiarize themselves with enough of it to deal with their own links? I'm sure they are familar with your view hierarchy since they are going to be building it, so it shouldn't be much of a leap to explain how controller and action paths work.
Razor files can be edited outside of a .NET IDE just fine...any old text editor will work since it's not like there's anything you have to compile. You could provide them with an instance that they could copy their files to via a shared drive (cifs) to test them on. I don't see any reason for your UI team to be required to use Visual Studio.
You could just rename your .cshtml file to .aspx and reload it in VS and design away. when you are done, rename it to .cshtml
Related
I am building a web project in Visual Studio that uses dojo, but I am unsure of how to link in the 3rd party dojo files so they get copied to the output directory.
In the past for things like jQuery, I placed the jquery.js file in a separate folder, went to "Add Existing Item," added jquery.js as a link, and set Visual Studio to copy it to the output directory (if newer). This worked great.
For dojo, there are hundreds (if not thousands) of related external files. This is not practical to add to Visual Studio (though I did find a way to do it in bulk).
This makes me think that I am approaching this incorrectly. How can or should I include something like dojo in a C# project without having to reference each file? Should I use a post-build step to robocopy the files into the output directory?
My goal is to be able to build multiple projects which all use dojo, but I don't want to have multiple copies of dojo checked in, or have to reference each file in the project.
Use the "Add as link" feature of Visual Studio.
http://msdn.microsoft.com/en-us/library/vstudio/9f4t9t92(v=vs.100).aspx
. . .
I am also a Dojo user. You will want to learn to do Dojo builds, to reduce Dojo to just a few files, and host them on your server. In many cases, in lieu of that, with some tiny loss of efficiency for the first load (after that, caching takes care of things) using the one of the CDNs like google to access the Dojo files is also effective.
Depending on your particular circumstances, it may be better to put the files out on a server, and just reference them in your HTML templates. This is, for example, how we do all our internal Dojo applications in my organization--three developers use one set of Dojo files for all applications.
I want to ensure I follow best practices in the context of ASP .NET MVC 3. I am using the Razor template engine to generate automated e-mails when certain actions are performed on an MVC 3 web application.
I have created a separate class library for the e-mailer and this class library will contain the models that will be used when generating the emails as well as a message factory which will generate the necessary message text using the appropriate view and model.
I am unsure as to where I should be storing my view templates. I would like to store them as CSHTML, as this will allow the developers on the project (who are new to Razor) to use IntelliSense while creating the mail templates.
I don't think I can store them in a folder in the class library as this will make deployment more complicated. If I store them in a folder within the MVC 3 Web Application root, they will be accessible to anyone on the internet with knowledge of the correct path. I now consider two options:
Store them in the app_data folder, but this seems untidy.
Store them in a folder called "EmailTemplates" within the Views folder in MVC. I think this is the best option as you can not browse to it directly (no controller) and our developers can access them easily and make use of IntelliSense.
Is option 2 the best option, would it be a sin to have these mail templates located here? I would then access the files directly through the local filesystem but I am not sure if I will have security issues once deployed to production (perhaps using the app_data folder would prevent this). I would like minimal configuration for deployment.
Thanks!
As usual, there's no one right answer, its all about philosophy and approach, but most important (in my mind) - utility. I.E. if it works, easy to maintain, understandable - why not do it?
I would, in your shoes, put it under App_Data folder - this is by definition where all data that application uses goes. Database is there, configuration XMLs are there etc. So why not use that folder for your purpose.
You can easily access it like this from within your C# code: System.Web.HttpContext.Current.Server.MapPath(#"~/App_Data"). I don't think any other (created by yourself) folder will be any better or worse ... its just App_Data is there specifically for these purposes, but it doesn't mean you cannot do something else, that makes sense in your application.
Hope this helps.
After doing more research and some experimenting, the Views folder seems to be the best place for my email templates. Here's my reasoning:
The email templates will only be used by the web application and nothing else.
The application pool the MVC application will run under, will at the very least have access to read the folders within the Views folder. This means I don't need to cater for any special permissions for folders during deployment. (Although this is true of the App_Data folder as well).
IntelliSense does not work from within the App_Data folder but does work within the Views folder. As the developers on this project are new to Razor, IntelliSense will make things easier for them. Also just makes development of the templates easier.
Although I created a separate project for the template mailer, one
can store the models for the mail templates with your MVC models as
well.
In most .NET project I can use folder to organise the code files. In C++, I can't, but filters end up playing the same role. However, in F# with Visual Studio 2010, I can't. Every code file is shown directly in the project dir. Why is this feature not available?
And what is the optimal strategy for organizing a project with a lot of files?
Actually, you can add folders to F# projects but it's not supported directly through Visual Studio (you have to edit the project file yourself): http://fsprojectextender.codeplex.com/ (edit: old link was broken, updated to F# Project Extender home page which has links to the original blog posts which were moved) (which I found in this answer).
I do this myself, but it is cumbersome and you end up avoiding it until keeping sanity really demands it. I think the feature simply slipped, or perhaps there wasn't as much a culture for folder organization with the F# designers in the first place. You can see in the F# source code that they favor huge source files with no directories, with separate projects as an organization boundary.
I imagine the F# project template could be modified to support this, and it is certainly something I'd like to see happen. At the same time the linear compilation order F# enforces causes your code to be somewhat self-organized, and so folder grouping plays a less significant role.
Manually editing the .fsproj file as described in Stephen's answer is one option (and I used it when I wanted to organize one larger project).
However, you have to be a bit careful and I think you cannot add new files to the folders (creating a file by hand and then adding an existing file works). However, if you like to keep things organized (like I do), then it should work for you.
Additionally, there is also a tool called F# Project Extender that should make things a bit easier for you . I have not tried it yet, but it looks like it supports adding folders (and perhaps other useful things). See for example this blog post by the project author.
Currently I have 4 solutions that are independent projects, however there is quite a bit of duplicated code when it comes to a few areas of the applications.
At the moment it is simply a few forms and their associated code.
When I want to change or improve something, I have to copy and paste to all relevant projects.
I looked at creating a new project within one of the solutions for the .dll/class library, but I felt that this was incorrect. (Please say if I am wrong).
As it is a component for all the applications, I decided to create a new solution for the .dll/class library and am looking at moving the shared code over to that - but, having never gone down this route before, what are my options from here?
Am I able to then include this solution within the others if I need to make a simple change and have it updated in all the projects or instead, should I always be working on the shared component in a separate instance of Visual Studio, outside of the applications using it?
That's exactly the right way to handle this situation.
You can include projects in multiple solutions by right-clicking the solution and selecting Add Existing Project...
Any changes you then make will appear in all solutions. The only problem this leads to is that it's possible to break one solution from another. This is where automated builds on commit to source control come into their own.
Put shared codes in separate Solution/Project as Class Library,
In post build event of shared projects copy dll's to a specific directory,
Add shared dll's from this directory to other projects/solutions
By doing this each time you build your consumer projects, they will use latest dll's automatically.
Moving the common code into a separate shared assembly is an excellent option.
One thing to think about is to keep your common business logic or business object type code separate from UI related code like custom controls - if you need to then have two common assemblies. This is more work initially, but makes things way easier further down the track when you need to make UI changes or change the control suite you are using.
How do I create a Web Application Project in VS 2008? How is it different from a "WebSite" project?
File--New--Project
instead of File--New--Web Site
It acts as a different container all together and the compile model is different.
ScottGu provided some details when they were first launched: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
The main difference is that Web application uses .csproj file which holds the information about all the files in the project. What difference does it make? Using web site model you can add new files without visual studio, since adding new files doesn't require csproj file modifications, but using Web application model you can not.
I personally prefer Web application type.
People have adequately identified many differences, but let me add this broader stroke:
Web Application Projects are architecturally consistant with the other project types in .Net, whereas WebSites deviate and really seem like a throwback to the VS 2003 days.
For this reason, my opinion is that WAP's are more elegant (especially when you have more than one project in a solution).