I have a solution with multiple projects and a website. On each project I have set up a pre build event to get the highest subversion revision number of the project (using SubWCRev) and then replace part of the AssemblyVersion with that revision number.
How do I achieve this on a website? As far as I can tell there is no pre build event and if I try to:
Add another project
Make the website dependant on the project
Use the pre build event for the project
The subversion revision number used to replace information in the website will be for the project not the website.
Any ideas?
One suggestion might be to use a Web Application project - rather than a Web Site project. Although this might not be entirely feasible in your case, depending on the amount of work required to essentially migrate the existing code-base.
See this question and its answers for more information: ASP.NET Web Site or ASP.NET Web Application?
Related
I am looking for some guidance on the standard way of implementing plugins in D365 CE or what Microsoft recommends.
I generally follow this practice -
1. Have only 1 CRM Solution and one plug-in assembly (DLL) for all these plugin steps.
2. Have a separate ".cs" file for each plugin in this project.
3. Each plugin corresponds to specific functionality. So in case, we want to disable any functionality, it could be easily done without changing the code.
4. Have only 1 CRM Solution for all these plugins.
Looking forward to some expert guidance.
Thanks!
In this video former MVP Mitch Milam talks three plugin solution layout options. He recommends the approach you outline above, and that is the one I typically use.
I also generally use a Console app to test and debug plugins. For maximum flexibility, I often put all the business logic into a Visual Studio shared project. Then I reference that shared project from both the plugin project and the Console App.
While the Console app could reference a DLL, having the logic in a shared project easily allows me to also use the logic in a workflow project if I want. Ultimately, the shared project gives me the option run the code as a plugin, a workflow, or a Console app.
Here's an example:
The .Cmd project is the console app. The one with the double diamond icon is the shared project (which cannot be compiled on its own - it must be referenced by one or more compilable projects).
I am trying to integrate Blogengine into my existing .net website.
I found this page on stackoverflow, Is there a stable ASP.NET blogging control (designed for integration within existing site)?
step4 says, "4:Add the Blog Engine.core project in the Web Application. Build Blog Engine.core and add reference from your web project to “BlogEngine.Core.dll”.
What am I specifically supposed to do in this step?
Thank you!
Download the BlogEngine from http://blogengine.codeplex.com/releases. You should take the source version. It contains: BlogEngine.Core, BlogEngine.Net and BlogEngine.Tests.
You should take the project "BlogEngine.Core" and copy it to your solution, and reference it from the website where your blog is.
We currently have CruiseControl.NET (v.1.6.7981.1) running on a 'development integration server.' We have a number of separate .NET sites that operate under the same IIS site and therefore share a 'bin' folder. This is the required setup due to the CMS implementation.
With a shared bin folder, an assembly change from one site could throw an error and affect all the other sites.
What we do is build and deploy the single site that we're currently working on to the integration environment and then spot-check the other sites to ensure they are still working.
In order to have more immediate feedback on the builds, we are looking at utilizing triggers to build all solutions at the time of a checkin of any solution. Ideally, we would like to avoid having to edit each project's configuration when a new site is developed and brought into the integration environment.
Does this sound like a sound approach or is there a better way to go about this?
Thanks!
I am setting up a CruiseControl.Net server. So far, it only builds a project (.Net website), and I kind-of know how to set up unit testing, code coverage, etc in the future.
What I will need to have soon is this:
The developers commit changes to SVN continually, thus CCNet builds often.
CCNet will publish the latest version to the development server, as soon as a commit is validated (with unit tests etc).
The project manager validates a specific version, in order to publish it to the pre-production server, and create a SVN tag from this revision.
The last point is where my problem lies: how exactly can I set up things so the project manager can, for instance, browse to the CCNet web dashboard, select a previous specific build, and says "this is the build I want to publish" ?
I believe that my thinking is flawed somewhere, but I can't put my finger on it. Maybe CCNet is not the right place to do these manipulations ?
In my mind, I can create a SVN tag using CCNet, and mostly work from the trunk, but maybe I can't ? Maybe it's the other way around, and I should add a CCNet project every time a tag is created under SVN ?
The final goal is that I want to automate the publication process: zip creation (for archiving), web.config modification (using Nant for instance), and website publication (using FTP).
In all these steps, I want to limit the manual intervention to the maximum. If I can avoid to add a new project to CCNet every time a tag or branch is created in SVN, that would be awesome.
Thanks for your help, and sorry if it's not very easy to read, but it's not very clear in my head either...
Since you can create any task, you should be able to achieve the goal, though unfortunately not out-of-the-box.
Since you use SVN, it all depends actually on revision. I think I'd create a separate project for your third scenario and added a parameter where PM would provide revision number. Then based on that I'd tag sources etc. in my own task.
Regarding the other points, I think this is similar. Recently for web projects we started using MSDeploy, and in each stage build the MSDeploy package was created. Then there was a separate build called Deploy, that when forced allows us to select which package we want to deploy using MSDeploy.
Having several environments, however, started a little bit like overkill for managing with CCNet, and I'll be looking into kwakee at some time.
I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests