We want to deploy a couple of static content files in the service fabric package (configs, metadata). As long as those files are in the root of the package, everything works fine. If we however put them in a subfolder, the files are not included in the package. Is this some kind of bug, is this by design or do we need to configure something?
Update
It seems that the problem is in our own custom deployment code (we package and deploy to service fabric ourselves). This is indeed working, as long as the files are marked with Copy to Output Directory.
Make sure that you've updated the project metadata for any such content files so that the "Copy to Output Directory" property is set to "Copy Always" or "Copy if newer". If the file doesn't show up in the service project's bin folder after executing a normal build, then it for sure won't end up in the generated package.
Related
We run JBoss 6 in standalone mode. We do have a folder (content.war/) in deployments that contains a symlink to a different folder (let's call it docs). Symlinking is enabled in jboss-web.xml with <symbolic-linking-enabled>true</symbolic-linking-enabled>. Our scenario is to use this to serve static files via this app context.
We do deploy the folder using touch content.war.dodeploy. It all works fine when the docs folder contains just few files. When the docs folder points to actual folder that has around 30GB the deployment seems to be stuck (the folder is not deployed and no other deployment works afterwards).
I believe that JBoss tries to somehow traverse or scan the whole folder. Is it possible to somehow disable this behaviour?
One workaround seems to do the trick. I can deploy an empty exploded war folder and once it is deployed I create the symlink to the huge folder.
Disadvantage: When JBoss is restarted it gets stuck again. I'd need to remove the link and create it again after deployment.
Another option is to use welcome-content that JBoss uses to serve static content. I can remove the original welcome-content folder and create a symlink to my folder instead.
ln ‐sv /home/mypath/my-static-content ${JBOSS_HOME}/welcome‐content
Disadvantage: This doesn't allow you to use any symlinks inside your folder or subfolders.
I'm trying to use teamcity deployer plugin to send my build result (war file) via ssh to another computer in network.
my problem is how to config deployer to find my builded war file.
I used %teamcity.build.workingDir%**/*.war in Artifacts path setting but it can not find any file in there.
The log show that it try to find my file in here /home/teamcity/TeamCity/buildAgent/work/c4bca27d2b00a6fe**/*.war.
the path is correct but It's not working...
the teamcity document for Accessing Build Artifacts is not clear, and does not show what should i use in setting dialog.
Update:
I tried to use **/mywar-1.0.war and **/build/libs/mywar-1.0.war, both works but now the problem is, it deploy the file with it's subdirectories like this dest/build/libs/mywar-1.0.war
but i need dest/mywar-1.0.war,
so still don't know how to configure it...
Teamcity deployer plugin, uses pattern as a Artifacts path to find files for deploy, in most cases as #Vlad said using **/*.fileType or **/filename.type is enough,
for example : **/*.war or **/myprojectfile.war
but sometimes your output files are in subdirectory tree, so using pattern case the deployer to create those subdirectories on destination.
in this case, I just need the war file without its subdirectory so the right way is using complete path to that file.
for example :
my war file is in build/libs/ folder after build process
so using build/libs/mywar.war as a Artifacts path, will deploy the war to destination without its subdirectory.
Artifacts resolved under checkout directory as documentation says, so just **/*.war is enough.
Problem
When attempting to build an SSIS package deployment utility by right-clicking on the solution and choosing "build", the build fails with an error message similar to the following:
Error 204 System.ApplicationException: Could not copy file
"MyPath\MyFile.dtsConfig" to the deployment utility output directory
"MyPath\bin\Deployment".
---> System.IO.IOException: The file 'MyPath\MyFile.dtsConfig' already exists.
This error can be caused by casing differences in the configuration file path. In some instances SSIS will treat c:\MyPath\MyFile.dtsConfig differently than c:\mypath\MyFile.dtsConfig.
I tested this with two different computers connected to the same TFS server. One pc had TFS mapped to C:\Packages. The other pc had TFS mapped to C:\packages. Creating a package and running on the first pc would create the deployment without any problems. Trying to create the deployment package on the second pc would result in the could not copy exception.
I manually edited the .dtsx file on the second pc. Changing the casing of the configuration file path under DTS:ConfigurationString= in the .dtsx file allowed the package to work correctly.
To get the package to work on both computers I updated the local path for TFS to have the same casing.
Cause
This is caused when SSIS is attempting to deploy multiple copies of the .dtsconfig file to the output directory. By default, SSIS will copy both all dependent files (including .dtsconfig files) and any files added to the solution under the Miscellaneous folder.
If you have added the file to your solution, but failed to repoint the Package Configuration to the new location, both copies will be deployed, and the build will fail.
This scenario can occur when you:
Create a package using a Package Configuration with a .dtsconfig file
Copy the package to a new directory without editing the Package Configuration
Add the configuration file to the project by right-clicking the solution, choosing Add --> New Item, and navigating to the file
Build the package.
Solution
To fix this, repoint your Package Configuration to the file underneath your solution directory. This can be done through the editor, or can be done by viewing the XML code of your package and manually editing the path of the file, such as with the following:
<DTS:Configurations>
<DTS:Configuration
DTS:ConfigurationString="MyPath\MySolution\MyFile.dtsConfig"
DTS:ConfigurationType="1"
DTS:CreationName=""
DTS:DTSID="{93222D3D-7AFF-1F2D-9UB8-B5E7X256BBE5}"
DTS:ObjectName="MyFile" />
</DTS:Configurations>
Further reading can be found here.
I did a build publish to a mvc applications and See that packages.config is also deployed even though i did select "Only files required to run this application" in the properties. Can i safely remove this nuget package list file using wpp targets when deploying ?
Yes you can remove it from the deployed application.
It is used by NuGet to keep a record of what NuGet packages are installed in a particular project.
By default, the build process copies all files from source to the destination directory. To exclude the file, right click the file, select properties and for Build Action choose 'None'.
I am building a web service and am packaging it into a war file for deployment. Right now all of my config files (.properties and .xml) are being packaged into my .war file. This isn't going to work as some of these files will need to be modified for each individual installation. I know that some servlet containers will leave the .war files intact which would mean the config files would never be easily modified. My question is this: what is the best practice for deploying a .war file with these external config files? I'm thinking that the config files will need to be shipped separate from the .war file and placed into a directory that is in the classpath. Is there a default directory setup like this in Tomcat that these files can just be dropped into and my web service will be able to find without much trouble?
Maybe I shouldn't be using a war file for this setup? Maybe I should just be providing a zip file (with the same contents as the war file) and the deployment will simply be to extract the zip into the webapps directory?
I do not know any default directory in Tomcat to store configuration, my
attempts to solve the same issue have been :
1 - Move configuration to the DB and provide scripts or webpages to modify values.
2 - Have a script to deploy the war. The script would merge configuration from a user directory into web.xml or other deployed config files.
3 - Have webapps look first in a user directory for configuration and
if not found then look for configuration files deployed by the war.
Least favorite is 3 - it require all webapps to check two places for configuration and
you end up with two different xml files on the server with different values and it is not always clear which one is used.
Next favorite is 2 - the webapps can be written without knowledge of multiple config files, but you run into issue when someone does a deploy from Tomcat manager instead of using your script.
Favorite is 1. This just works in most cases. Problem is when you don't have a DB or
want to configure how you connect to the DB.
If having the file visible from all webapps is not an issue, you could put it $CATALINA_HOME/lib.
One solution is to modify property file after deployment of war file is to use ServletContext.getRealpath() method to get the real path means path of file in the server where it is deployed and then modify that file it will modify file in container only not the original file. So you need to backup it if it is important modification for you. So by this you do not need to redeploy war file as it is already modifying file from deployed container.
This solution can edit a file that is in webpages folder also from the java class.
If you want more description or how to do it then let me know i have did it.