I use Orchard CMS 1.10.1.
What is the best way to make a precompiled build of Orchard CMS?
All you need to do is open a command prompt, go to the root directory of your Orchard project and run the command build precompiled.
This command will build the entire Orchard solution and prepare all the files that you need to deploy to IIS. You will find those files in the build\Precompiled folder. This folder will contain only the binary files of your application and the configuration/manifest files (such as Module.txt, placement.info, etc). Those are the files you need to run your application in production. Specifically, there will be no source code files in the build\Precompiled directory.
Additionally the configuration files are tweaked for maximum performance. For example dynamic compilation and file monitoring is disabled. However, the view files are not precompiled and I'm not sure if that is even possible with Orchard.
Related
We are trying to adapt a build automation strategy for our ASP.NET web site (not a web project) in vs 2010 ultimate & tfs 2010.
Build definition makes the build and publishes the web site into folders like
<drop_folder>\<defn_name>\<defn_name>_<year><month><day>.<build no>\Release_PublishedWebsites
Now we try to delete particular files and folders from that folder. For instance the "images" or "files" folders, that we need to exclude before packaging. I know that if it were a web project, there exists a straightforward solution. We also tried to modify the build process template (xaml) file. There is a "DeleteDirectory" component but we couldn't figure out what to write to the Directory variable.
Thank you.
If you follow the XAML way, you would just have to feed the Directory argument of DeleteDirectory with the physical UNC path to the folder you 're trying to get rid of.Something along the lines of String.Format("{0}\\{1}\\{2}\\Release_PublishedWebsites", BuildDetail.DropLocation, BuildDetail.BuildNumber, Date.Now.Year)
should get you near to your target. Since the drop location of the build might be on a different machine, also ensure that the account conducting the build (by default = NetworkService) has the rights to delete folders on the target.
So I see two solutions to my current problem, but I was wondering what the pros and cons are, or if there is a defacto best practices approach.
So my current project has a number of configuration files, help files, and other external content. I need this content local to run and debug the application. Currently we duplicate this content in a standard windows installer project. This clearly is a bad idea. We are moving to a new setup that uses the WiX installer, and I'm currently setting the project up next to the code project and trying to figure the best way to share resources. I see two solutions.
One is that I can put all the resources in the WiX project and then add them as links in the code project. This way I know what I'm debugging is installer.
The other option would be to leave the content in the code project and path into it in the installer using the reference variables.
Right now it seems 6 one way, half dozen the other. Any persuasive arguments for either method?
Assuming that these configuration and help files are going to be installed in the same directory as the executables then definitely put them in the code project, mark them as Content, and add a reference to the code project to the installer project. If you're using WiX 3.5 the files will be automatically included in the installer along with the executables, which makes writing simple installers much easier.
For earlier versions of WiX or more complex deployment scenarios (where the content files could be going into different directories) you would still put them in the code project but then you'd use File elements with a relative path or reference variable in the Source attribute to include the the content files from the code project directory.
I don't believe that putting the content files in the WiX installer project directory instead of the code project directory will do anything to ensure that the version you use to debug will be the same as the version installed. That can only be ensured by thinking through the process of how your application finds these content files and making sure the right versions are found.
So going back to the simple case where the content is in the code project and marked as Content, and it will be installed and loaded from the same directory as the executables, then it is only a matter of setting "Copy to Output Directory" to "Copy always" or "Copy if newer" and then you can be sure the versions used in debugging and the version installed will match.
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I'm looking for a utility that copies all files from a VS2010 solution folder, which are necessary to build the solution, but ignores all other files (.obj files etc). My intended use is for emailing solutions or making them available on a blog etc.
I'd prefer a utility that's portable (runs without having to be installed), but if there is none, I'll settle for whatever's available.
You may want to consider something as simple as a script (via .bat or powershell) that simply runs the solution's build with a /clean and then zips up the entire folder structure into an archive.
No need to be fancy, especially when project can need any number of impossible-to-know files to build. (What happens when a new language is released like F#? If you'd written your tool 3 years ago, you'd have to modify it for that. What happens if someone needs a .txt file or a .mak file to build?)
In the past I've created a new configuration within VS.NET (e.g. Deploy) which builds the code in release mode. I also set the output path for the main application project to build into a separate folder in the root of the project.
If it's a web application, this is a little more problematic as it won't copy the support files. To get over this I use a nant script to copy all of the appropriate files, that are needed but aren't included in the build, into the aforementioned build folder.
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!