We are building a new SharePoint 2007 web site to replace our intranet website for the company I work for, and a common debate keeps coming up. Specifically, should we be using multiple document libraries (ex. 1 for each department), or one document library with multiple folders within (ex. 1 library with 1 folder for each department).
I know the benefits of using one document library and using custom views to organize the documents by utilizing custom columns (like department, purpose, location, etc).
Also, authorization can be set at either the document library or the folder level, so that does not seem to benefit either choice.
It would also seem that a single document could appear in multiple views in the same document library, but the document would have to be copied to other document libraries if that strategy is used.
The current plan is to use one document library for all organization documents, and then put a bunch of folders within, that symbolize the organization's structure. This would make it easy for a user to upload a document to their own organizational folder (with privileges assigned to that folder before hand). Then, when adding the document, they would choose custom column fields to identify the document and "tag" it, that will enable the custom views to filter the document into multiple views (like departmental, purpose, etc).
I don't think views are applicable for linking multiple document libraries to show their contents.
Anyway, the main question is:
Is there any benefit of using multiple document libraries vs. 1 document library with multiple folders?
Here is a diagram, explaining what I want to do:
Thanks!
There are a few times when you might want to consider using multiple document libraries as opposed to a folder structure within a single library.
Some of the things I can think of off the top of my head are related to settings that are configured at the document library level, such as
versioning
content approval
require checkin/checkout
having different available sets of content types
different workflows, or workflow configurations
etc.
Related
I have an application that uses Materialized Path to map a folder structure. Now I want to change it so that it is possible to link folders logically in multiple places (so a folder can have multiple parents). Is this possible with TypeORM? I've read a lot in the documentation and found nothing suitable.
I was wondering if there is a way to share the _layout.cshtml file across all projects. This way if I ever wanted to make a change to our companies page layout I only have to change it in one place. From the research I've seen so far people have made mention of possibly creating a .dll file. Also I'm not talking about areas in mvc. What I want is for all my separate applications to reference one shared layout page instead of each application having it's own layout.
Once pattern (which I've been involved in the implementation of) is to make a Nuget package containing the layout file (and anything else you want to share in common between all your sites, such as other CSS files, error handling routines, etc), and installing the package (from a private feed) into each project which requires it, thus overwriting the default layout file).
The source of the Nuget package is itself a C# MVC project with a custom nuget config which makes sure that it includes just the necessary content from the C# project into the distributable nuget file.
Apart from ease of installation and separation of concerns, another big advantage of distributing via Nuget is that if you make changes to the source files and update the package, each application which has the package installed can choose when would be a good time to update to the latest version (if at all), so you don't have issues where if you change one thing you have to change everything which depends on it all at the same time (For instance, the Add as Link option in Slappywag's answer would suffer from that problem - if you changed the layout file in that scenario it would immediately propagate to all the projects which use it, so if you wanted to make any other changes in that project you'd have to deal with any implications of the layout change before you could publish your other changes, which might not be desirable/convenient at the time.)
The way I've achieved this in the past is to use 'add as link'.
Firstly, add your layout files to a new library which can be shared between your different projects. Then in each of your projects which you want to use the layout page add the layout page as a link:
In solution explorer right click on the folder in whcih you want to place your layout file.
Click add existing, and select the layout file you want to use.
Click the little arrow on the right hand side of the 'Add' button, and select 'Add as link' from the dropdown. Your layout file will now be in place.
Depending on how your project is set up you may need to follow the steps in this answer to ensure your linked files are copied at build time. You may also want to make sure the copied files are being ignored by your source control.
Update your ViewStart to use the new layout file.
Any changes you need to make to the layout can be made to the original file, and on build changes will be picked up by your projects.
I have a project in Xamarin.iOS and I want to build it for different clients under different app ids with unique icons for each client. What is the best way to do this ?
There are many (many...) ways you could do this.
An easy one would be to create several application projects (.csproj) under the same solution (.sln).
Each project would have it's own configuration, defines, targets, even files (like icons). All sources would be links (i.e. file linking) from the master project.
That would allow you to customize/brand, build and publish each application separately, while maintaining a single code base across all of them (from a single solution).
Suppose that I have similar apps that share a lot of code. Paid and free versions, whitelabeled apps for different client companies, that sort of thing. In general, the differences between apps would be relatively minor; some images would be different, some text would be different, some kind of flag values would be different--the shared code would check for those values and change behavior accordingly.
A nice bonus, but not essential, would be for each app to be able to add code to extend/override some of the shared code.
I have read of several different approaches--there may be more I haven't considered.
one .framework file used in many repositories
I don't know much about this, but I gather it would be like making a JAR in Java; compiling code to be used as-is by other programs. This might work well for a general-purpose library to be used by many different kinds of apps, but as far as I know it is not suitable for the above purpose (correct me if I am wrong).
one repository, one project, multiple targets
From what I understand, this is most popular for the "one app with paid and free versions" situation, where there is only a very tiny difference between the apps produced--they are essentially the same app.
However, I don't know how flexible this is in terms of changes between the different targets. I gather it's possible to set a different .plist file for each target, and that can result in different text, flags or (through some kind of awkward workaround) different images for the apps, and that is it, correct?
I also feel uncomfortable with using one repository for multiple projects, but when they are this closely related, perhaps it doesn't matter.
one repository, one workspace, multiple projects
Although this seems to be a cleaner division among the projects, I'm not sure if there's a good way to separate resources for the different projects. The most logical solution would be to have different folders for resources for different projects, and include them in the workspace with only one target each--but I can't seem to do that. Apart from that, there seems to be little difference between this and the previous option.
So, what is the right way to make shared code for multiple projects that only have a few differences from one another? Is it one of the above methods (and if so, how do you do it?) or is it something different?
I prefer to have separate projects and a separate folder for each project.
You then bring each shared unit into the project as you need it. Shared features (most features) go in the shared units.
If you want to upgrade one project with the latest Rest.h and Rest.m, you bring it into the project folder. Maybe on the next project, you're not ready to upgrade to the latest.
You will have duplicate files (one for each project), but it allows you to update, test, and finely control each project atomically.
One repository or not, it doesn't matter, since the projects will have different folders and the shared files will be duplicated (possibly different versions in each, with the trunk having the latest shared files).
On a side note, I hope these many similar apps don't all end up in the App Store.
Has anyone used WiX to generate an installer for an ASP.Net MVC website? Do you harvest files from the web project? I can’t find any good examples of this being done. There doesn’t seem to be a documented way to include all the right files, only the right files and put them in the right place.
If you add the website project as a reference in the installer project, and set harvest=True in the properties, then all the website files are captured, but there are issues:
Some files that should not be copied are included, e.g. packages.config, Web.Debug.config There doesn’t seem to be any clear or simple way to exclude them (as per this discussion).
The .website dll file is in the wrong place, in the root rather than the bin folder (as per this discussion)
However if you do not use harvesting, you have a lot of files to reference manually (e.g. Under \Content\ alone I have 58 files in 5 folders. Most of that is jQuery UI) and they change from time to time, and errors and omissions could easily be missed from a WiX file list. So it really should be kept in sync automatically.
I disagree with the idea that the list of files should be specified explicitly in WiX and not generated dynamically (which is what seems to be suggested at the first link, the wording isn't very clear). If I need to remove a file I will remove if from the source control system, there is no need to do the extra work of maintaining two parallel but different catalogues – one set of files in source control, and the same files listed in WiX. there should be one version of the truth. All files in the website's source tree (with certain known exceptions that are not used at runtime e.g. packages.config) should be included in the deployment.
For corporate reasons I don't have much choice about using WiX for this project
In our MVC 3 project we use Paraffin to harvest files for the installer. For example, you can use "-ext " to ignore the files with extension , use "regExExclude " to ignore the file name matching the regular expression, etc.
Paraffin also keeps the proper structure, all your files would be in the correct folder as they appear in your project.
I use a program that I wrote called ISWIX that makes authoring wxs merge modules a simple drag and drop operation like InstallShield. I then consume that merge module in an installer that handles the UI and IIS configuration.
I also have postbuild automation that extracts the content of the MSI and compares it against what the project published. If there is a delta I fail the build and you have to either a) add it to the wxs or b) remove it from the publish.
I find that the file count churn from build to build is minimal and that this system is not difficult to maintain. The upside is everything remains 100% intentionally authored and files don't ever magically add or remove from the installer unless you intended them to. Dynamic installer generation isn't worth the risk and most people who argue that it is don't even know what those risks are.