We are currently moving over a large website to DotNetNuke (version 7.2.1). We're creating separate projects for each module and skin, source controlled in TFS. We were not planning on adding the actual DNN source code itself to TFS. I would like to be able to access common files, such as JS and CSS, among different solution/projects. Is there a recommended way to do this without source controlling the DNN source code project itself?
You could create local Nuget packages? :D That might be overkill for such a scenario.
You could always create a single project/module, that all the other modules reference the path for the original resources, so that they all point to the same location.
If you don't want to add any DNN related source in TFS, it means that you have to setup a identical structure on the disk and in IIS. Then in your ascx/css files you can use URIs that are either relative to your disk structure or your dev website.
If you create a specific project for the resources, you will put parts of the DNN codebase in your TFS. If it is not a showstopper for you, consider adding the elements to the solution instead, since there is no logical partitioning of these resources as a project. I would however recommend using URIs.
As a side note, please refer to the Client Resource Management API of DNN for your future devs in order to benefit from the minification and combination of resources.
Related
I like the way F# requires to organize files and code in order of dependency because it discourages mindless coupling.
I have flat list of source files atm (simplified):
Common.fs
Workflow1.fs
Workflow2.fs
And want to go one step beyond. First, organize files like this (VS 2017 can't move folders up and down, one needs to edit .fsproj but it is different story - at least it is possible):
Common.fs
Workflow1\Impl1.fs
Workflow2\Impl2.fs
I expected Impl1.fs and Impl2.fs to be fully isolated from each other because their folders are not in parent/child relationship, but Impl2.fs can easily see types and functions from Impl1.fs: just open module and they are available
Are there any techniques to keep them isolated? It's possible to split the project in three however I prefer to keep DLL as a unit of deployment: workflows are small and ideally I want to avoid to have many tiny DLL files.
It sounds like you have a good understanding of what your options are. You are not missing anything else. Consequently, the answer to your question is, "no."
You can't isolate the folders that way, as far as I know. However, if you want to keep them isolated at compile time but deployable as a single unit, you can create separate projects and use Fody or ILMerge to combine the assemblies post-compilation.
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
I've created a web app (mvc4) that I'd like to reuse in multiple projects. The site is an admin panel, but it may be extended and slightly modified in each project. I want to avoid copying the project over, because I'd like to be able to update each project to the latest version at the lowest possible cost.
So far I have tried 2 approaches:
a script that 'clones' the project by copying all the necessary things as well as altering others (guids in assemblies, namespaces and things like that) - this works fine for extensibility and modification, but that's just a copy so pushing 'updates' is a mess (I did it manually) and it does not scale.
portable areas from mvc contrib project - this seemed like a good idea at first, but it turns out that it's nice for simple scenarios, but fails at more advanced use cases. It doesn't support localization (from resources embedded in the portable area), bundling and min requires a lot of hacks (mvc contrib is still on mvc 3), it's not possible (out of the box) to reuse shared views or Display/Editor templates from the portable area and it looks like if I'd go further that way, some new things would come up
Currently I'm thinking about 'just' branching each project from the core one. This would of course require the same changes (or at least a big subset of them) that were done in the script I mentioned earlier, and I'm afraid that if I try to pull updates from the core project the number of conflicts will render the whole approach unusable.
Does anyone have an idea on how I could tackle this problem?
I'd suggest to create a NuGet package of the mvc app and reuse it. So versioning and applying updates would be much easier. However it takes a bit work to make your code completely isolated from the codes you want to add in the new project.
I have a visual studio solution with multiple telerik MVC4 razor projects having same look and feel. I don't want to have same layout, CSS/styles, images and js files copied in all MVC4 projects. What is the best way to accomplish this re-usability? I tried creating a virtual directory of a commonUI project and tried to refer _layout.cshtml using http://localhost/... in _ViewStart.cshtml but it complained saying "http:/localhost/MyMvcApp/Views/Shared/_Layout.cshtml' is not a valid virtual path."
Please help!
Four recommendations:
1) Look into areas, maybe instead of having separate projects these are really different components of the same system (admin, etc.)?
2) Use add existing item in visual studio and add the items via links. This still duplicates them for deployment, but you can keep one source.
3) Consider doing this by building your own nuget package. That way although you would copy the CSS and images you would have it packaged up and could update the package as needed. The benefit is that you can update one project while not having to re-test the other (if they are separate and 1) doesn't apply).
4) I find this one uglier than the rest, but in IIS I believe you can map in folders, so you could refer to these files by links in your project, not deploy them there and then map in the appropriate folder at deployment time using a single source path.
I know of no way to share up the application path.
EDIT:
I have never tried this before, so can't vouch for it working, but maybe compile your shared items in a separate project and then reference the DLL in all other projects.
The reference I found is this, but again, I haven't confirmed that this works, just think this could be a viable path to explore:
http://www.chrisvandesteeg.nl/2010/11/22/embedding-pre-compiled-razor-views-in-your-dll/
Areas are bad because you cannot deploy them separately. Like you, I tried using virtual directories, and was successful referring to the layouts using relative syntax:
#{
Layout = "~/Common/Layouts/Layout-001.cshtml";
}
Above, the project's layout inherits the layout in the /common/ virtual directory at the root. As the common layout (along with it's bootstrap & jquery versions) evolve, you can use side-by-side version-named physical folders (like common.v01, common.v02,). So you can upgrade your applications to a newer common layout by changing the VD's path to the appropriate version.
The downside with this is you'll need to use IIS (not express) as your dev and test platform.
I've got a common Layout.cshtml file that I want to share. When I add the file as a link in the project (via Add Existing Item > Add as Link) I get an error that it cannot be found when I run the application. If I set the build action to "Copy Always" it does copy the file to the build directory, however I still get an error that it cannot find the file (Perhaps I can somehow instruct VS to copy it to the appropriate directory?).
I came across this question: ASP.NET 2 projects to share same files however the answers are pretty complicated and ugly and right now I'm playing around with a lot of different structures and refactoring methods so I don't want to go through some big production just to move a few different files around.
So how can I easily share these kinds of files between the two applications?
Thanks!
You cannot Add as Link static files in an ASP.NET web application. All files need to be included inside this application or when you deploy it in IIS simply won't be able to find any of them. A common technique of sharing static files between multiple web applications is using CDN (Content Delivery Network) where you would host all your static resources (images, CSS, js, ...). For example Google already provides popular frameworks on their CDN.
So for all your custom images you could setup a domain on your web server which will host them all and your web applications will point to this common location. Another advantage of this technique is that clients visiting those applications will already have all static resources in cache.
Looks like it's a bug in msbuild or an unsupported feature. Either way I finally found a workaround published on this guy's blog:
http://consultingblogs.emc.com/jamesdawson/archive/2008/06/03/using-linked-files-with-web-application-projects.aspx
Someone else might give you a better solution, but my approach would be to:
1 - Create a library project
2 - Create a Resources file in the library project
3 - Add the shared resources to the library project.
4 - Compile the library project
5 - Reference the DLL for the library project in the dependent projects