I've created my own deploy.cmd for customizing my app's behavior when pulling new code but, unfortunately, I can't see it in the site\deployments\tools folder where it usually belongs.
Typically, the file is auto-generated and placed in the tools folder automatically and I've been successfully modifying it. I've been advised to simply place it in the root of my repository and it will be handled automatically. After doing that, I'm unable to find the deploy.cmd file in the expected place.
Where is it?
It is normal for it not to be there when you use a custom deployment script. It only ends up there when your script is generated.
Generally speaking, you should never modify this file when you see it in the tools folder. It is stored there as a cache for the system. You either use a custom deployment script, or you end up using the generated one.
It sounds like you forgot to add a .deployment file alongside deploy.cmd. Without it, it will be ignored. It should contain:
[config]
command = deploy.cmd
See this post for details.
Related
I have an executable that I want to be deployed together with my Azure web role. The executable has a configuration file that needs to be included as well.
I tried adding a reference to the executable's project in my web role project, which made the exe file appear in the bin folder of the cspkg, but not the configuration file.
How can I get the configuration file to be included as well?
It seems wrong to include it directly as a content file in the web role project because this file is a build artifact (app.config gets renamed to .config.exe during build).
Thanks!
In an early SDK they added the concept of Role Content folders, or folders you could point to in the service definition file and say anything in this folder, add it to the package and deploy it with the role. If you look at the schema for the Service Definition you'll see these listed on the both the web and worker roles schemas. You can manually add this and point to any location on the local system and anything in that directory will be picked up and included.
<WebRole name="SimpleWeb" vmsize="Small">
...
<Contents>
<Content destination="ConsoleApp">
<SourceDirectory path="c:\src\SimpleWebContent\ConsoleApp\BuildOutput" />
</Content>
</Contents>
</WebRole>
For example, you could point to the output directory of the build for your executable so that anything that is generated by your build for that executable would be included. You can set the destination directory in relation to the app root, but the tricky part is the source directory. Note in my example above the full path is provided. The documentation says that you can use a relative path, but I tried many combinations and the behavior seemed very quirky. The complete path does work.
The VS SDK tools didn't expose this until SDK 1.7 and it's still not very good. Phil Hoff did a blog post on it called "Add Files to your Windows Azure Package using Role Content Folders". Note that when you use this method of adding the files you won't see the content elements appear in your service definition. They get auto injected at package time. If you are doing this as part of a build process that may not happen since VS tooling is doing the injection, but to be fair I didn't try calling cspack directly to see if having the content elements included in the service definition file actually packaged those or not. Also, I found that just adding a new folder and just having files under that folder didn't seem to work. I had to actually add the files by name there, which seemed wrong. I did hack the .ccproj file to use a wildcard on the folder include, which did work, but also seemed like a hack to me.
Maybe someone can advise me.
I am trying to publish a project using VS2012. I have setup a publish profile to publish it to a file system drive.
I have several environments/build configurations required and thusly am using Web.Config transformations.
At the moment, I have a web.config + 5 transforms (one for each build config). When the solution is published, it successfully deploys to the file system specified. However it also transforms the Web.Config into web.config.
I have modified the .pubxml to include the <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element, but the publish process just seems to ignore it and transform the web.config regardless.
Followed via this link: http://msdn.microsoft.com/en-us/library/dd465342(v=vs.100).aspx
Can anyone advise?
[edit]
I have tried putting <TransformWebConfigEnabled>False</TransformWebConfigEnabled> element into both the pubxml and the proj file and both ways it get's completely ignored and the web.config is transformed regardless.
You are sticking it in the wrong file. You want to modify
YourProject.csproj
instead of PublishProfile.pubxml.
So in Azure, I created a cloud service, and now I want to upload a deployment. It asks for a package (sure, that's easy, a zip file) and a configuration file (.cscfg file). I understand that the .cscfg file is supposed to define the roles, network configuration, etc.
But I don't have a cscfg file. Where are they supposed to originate? Do I have to write one by hand? The documentation for that is substandard at best. Is there any way to generate one? Or do a deployment somehow that bypasses this step? My approach must be wrong on some level (unless I really do have to write one by hand, but I somehow doubt that is a typical case).
You can either rely on Visual Studio to create it or manually create with command line tools.
http://www.microsoft.com/en-us/download/details.aspx?id=15658
You can also create using msbuild:
http://msdn.microsoft.com/en-us/library/windowsazure/hh535755.aspx
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works
CruiseControl.NET service needs to be restarted to pick up changes in the projects configuration files.
I find this very annoying, not sure if it's a bug or it's the way it works.
Is there any way to overcome this issue in people's experience?
If your projects are separated in a different file from ccnet.config, then you need to restart the service unless you touch the actual ccnet.config.
We use ENTITY with SYSTEM file reference in ccnet.config for our projects, so we're in the same boat. I'm happy to pay the price for easier project maintenance, as it's easy to script a restart:
net stop CCService
net start CCService
IISRESET
If you wanted to completely automate this, and had your projects under source control, then you could trigger an update and restart whenever your project files are touched.
There was a bug in CC.Net prior to 1.4.4 if you were using a pre-processor include it did not reload the configuration when an included ccnet.config file was modified.
That was a bug that I reported and it is fixed in CC.Net 1.4.4 and greater.
Also, keep in mind that if a build is running and there is a change to the configuration it will not take place until that build is in an idle state.
How are you updating your config files? By hand? Mine always recognizes and adjusts. Is your config file in source control and designed to pull it down and replace the file? This for me requires a kick. How I ended up fixing it was have my project pull it down to a seperate folder. THen I call ccnet.exe -validate on it to make sure it is well formed, then I copy it over ontop of the current config file. CC.NET recognizes the changes and loads in the new config
Exceptions: If cc.net is currently running a project, it will not recognize the changes till that project has completed.
If your ccnet.config has errors, it will not ever recognize the changes and keep running the old version it has stored in memory. (However when CC.NET does restart it will try to parse the error filled config and choke.
Hope this helps!!
Do you mean you are using linked files, that is the ccnet.config file has links to the independent project files.
If so then they are not picked up, it's mentioned in the documentation that it doesn't watch the sub-files.
Internally we have modified our CruiseControl.net so that our ccnet.config is optionally a directory - and we can drop shortcuts to our project config files into that directory. We put watches on the directory, the files or shortcuts in the directory and all of the targets of the shortcuts. That means we have our project config files in ClearCase and just drop a shortcut into the ccnet.config directory.
I've just spent half a day or so moving from 1.2 to 1.4.2 dropping our changes into the new version for our internal use. We don't own our code, our client does and so it has to stay internal :(
I have never experienced this. Whenever I change the configuration files, the CruiseControl.NET service seems to automatically re-read them.
I'm using Version 1.3 of CC.NET.
Update:
In the service's config file (ccservice.exe.config), there is a setting to enable/disable watching the ccnet.config file for changes:
<add key="WatchConfigFile" value="true"/>
Make sure this is set to true.