Inside maximo anywhere we have 4 apps out of which i want only work execution app to be build and deployed.
Currently ant build is building and deploying all apps which is time consuming. Please help
It's in the build.properties for the solution.
Check here for some more info on it. The build.properties contains the variable aspects of the build process and defines the target server to which an app is deployed. it can be found here: maximoanywhere_home\AnywhereWorkManager
In order to specify the applications you want to build, you're looking for "appsToBuild" property in build.properties as mentioned.
appsToBuild=WorkExecution
In order to limit what apps are built, you will need to edit the "appsToBuild" property in the build.properties.
However, this does not apply to what apps are deployed. In my experience with Anywhere apps for iOS, all IPA files that are in the bin folder are deployed, not just the ones specified in the appsToBuild property in the build.properties file. This can cause problems (such as deploying an app that was not built for the server you are deploying to). To prevent this, delete the contents of the bin folder before running the all-dist command for the build ant script. Then when the all-deploy command is run, it will only deploy the files that were recently built to the server.
Related
I have an ASP.NET (4) Web App solution with 3 projects. Project A references B & C (along witha bunch of other 3rd party DLLS like Crystal Reports etc).
I have 3 build configs, Debug, Test & Release.
If I do a build in any of the configs, the built DLLS (and PDB if it is Debug) are placed as they should in their respective folders.
So Test gets built into {root}\bin\x86\Test
Release into {root}\bin\x86\Release
Debug into {root}\bin\x86\Debug
Also, all the dlls that are referenced have their 'Copy Local' property set to true and so they are copied into the {root}\bin folder so I can run and test locally in VS.
BUT
The main app DLL (ProjectA.dll) is not being copied into the {Root}\bin folder when it is being built/rebuilt, just being left in the folder for the chosen build config as described above. So when I run the app in VS I get an error 'Could not load type 'ProjectA.Global_asax'. Not surprising given the main project DLL is not in the Bin folder where the web server is looking for it.
The only way I can get it to run is to manually copy the ProjectA.dll into the {Root}\bin folder myself which seems a nonsense and obviously fraught with the risk of me forgetting to copy the latest on over after each build.
Surely there must be a way of telling VS to copy the main app dll (ProjectA.dll) as well as all the referenced dlls, into the main {Root}\bin folder?
Obviously, as ProjectA.dll is the main app assembly it is not in the list of references so I cant just set the 'Copy Local' prperty for it. Unless it is hidden away somewhere else? I have trawled every form and dialog in VS (and hours on Google!) and just cant see how to tell VS 'Please copy the main app assembly back into th bin folder when you have finished building'.
Can someone pls help ths is driving me nuts!
Many thanks
Mark
If you just want avoid the manual work of moving the dll after every build, then you can create a Visual Studio post-build event to copy the dll. Some examples here and here.
I am using Visual Studio 2010 to manage a web application. This web application is organised into a number of projects, where the UI itself is one project, and the business logic resides in another assembly which is then set up as a project reference for the UI, and makes calls out to code in third-party libraries.
When I do a deployment build, MSBuild creates the usual _PublishedWebsites folder and copies the web application into there. What it does not do is copy the dependencies of the business layer, which means nasty YSOD when I try to run the application. Now, I can set the third-party libraries as references of the UI project, and that ensures the libraries are copied and deployed as expected - however, that rather misses the point of having the business layer doing all the work, and means additional maintenance in that when another third-party library is added, it needs to be added in more than one place.
How can I ensure, once and for all, that dependencies of my business layer are deployed to the _PublishedWebsites folder when the deployment build is run?
As per my comment to #Shaun Plourde's response, it appears that this scenario is not supported. If you want indirectly-referenced assemblies to appear in the build output, you'll need to reference them directly.
This should just work out of the box with VS.NET. Try setting "Copy local" to true where the dependencies are actually needed. Your UI project should not require any explicit references to those assemblies.
For smaller projects, this may scale fine in terms of compilation performance. For larger projects, you may want to consider alternative approaches such as those outlined in Patrick Smacchia's article at http://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/.
It isn't a perfectly automated solution, but you can solve this with a post-build script on your main project.
I've found that the $(WebProjectOutputDir) variable is managed such that it resolves to the "_PublishedWebsites" directory when you supply an output directory that is not equal to the directory of the project being built. (Otherwise, it is the same as the current project directory.) So, for your problem, you could put this in the post build of your web application:
xcopy /Y /S "$(ProjectDir)..\Your Business Logic Project\bin" "$(WebProjectOutputDir)\bin"
It should work both on your machine and on your build server.
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
we have this problem but can't find a solution. We have an application that references something like 24 dlls. When you invoke the application the very first time (after the application is for any reason reset) it takes 25-40 seconds to start loading contents.
This is what we tried:
1. precompile and publish everything in release mode
2. removing pdbs from bin folder
3. put strong named assemblies into GAC
4. set application to debug = false
Please consider that the whole bin folder is composed by 24 dlls for a total size of 28MB. Just 4 of these dlls are strong named and they are more and less 25MB.
Nothing seems changed. What happens EXACTLY when the application is started is something I couldn't find in any book nor forum/blog/post... What can we monitor more to find where the problem is?
Thanks a lot for your help,
Marco
Looks like you will need to use NGen...
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead using the just-in-time
(JIT) compiler to compile the original
assembly.
Precompile the website for deployment, using fixed names, deploy the solution to the server, and then ngen all assemblies in bin
MSDN article on NGen.