I want to deploy some front end assets to the local web root of a site using file replacement. I can't seem to get it to work with a relative path in the target location field though. Is it possible to do this though tds or should I use a post build event instead?
The reason these assets aren't included in a project is that they are part of a third party solution but we still want this tracked in source control to try to make the project setup easier.
Most developer machines will be set up the same way for this project with the same file structure but I think it's a little more flexible if I can make the target a relative path so I don't need to worry about differences like drive letters and such.
The folder structure is as follows:
repo
folderToCopy
sitecore
webroot
I have tried the following using ..'s based on what tds changed my source location to be while using the "Make selected Source Location relative" option (changed it from an absolute path to ..\folderToCopy\):
../../Sitecore/Website
/../../Sitecore/Website
..\..\Sitecore\Website
\..\..\Sitecore\Website
From my understanding, TDS does the file replacement based on the files published from the associated Website project.
You can then have relative replacements such as the following:
<Replacement Include=".\assets\folderToCopy\myFile.txt">
<TargetPath>.\assets\targetFolder\myFile.txt</TargetPath>
<IsFolder>False</IsFolder>
<IsRelative>True</IsRelative>
</Replacement>
I have not been able to successfully get TDS to use the file replacement with files that are in source control but not in the project.
My suggestion would be to set up a build event that will copy these files to the correct location, or to create a nuget feed for them and pull them in as nuget references.
Related
I am writing a number of Google Packaged Apps which run independently, but share lots of code. For example, they all use "library.js". I would like to have only one copy of library.js so any changes to it will be used by all newly packed apps.
To package my apps, it seems they all must have a copy of library.js in their own directory structure, whereas it would be nice to have a single master copy in some other directory that is accessible to all. I currently do a manual check to make sure all files are up-to-date before packing, and I am writing some code to do the check automatically, but it seems like a work-around.
Can a Google Packaged App use JS code in external library directories, or must all code be under the root directory of the app (i.e., requiring copying from external directory) when packing?
Have you tried providing a URL i.e. host the javscript file in .js format to an accessible location to your apps and then provide the .js file URL in all your apps code. The very next time you want to change, all you have to do is to update that .js file.
Is there a way to make Progress Developer Studio 3.7 (Eclipse) generate all the wrx files (from the ocx) and place them in for example the rcode folder?
Clarification:
I dont know even how to make one wrx file. Have heard this "They get automatically created as soon as you drop an OCX control onto an ABL frame". But if you have removed that file, can you create it anew without having to redrop the control? And how do you automatically place it in a certain folder?
wrx files contain the properties of an ActiveX you set in the appbuilder.
If you loose the wrx, those properties revert back to default values. You should check-in the wrx files into your version control system together with the source .
To copy the wrx to the rcode directory I use robocopy.
suppose your sources are in a directory named src then you can copy them using
robocopy src rcode *.wrx /s
The wrx-file is generated when compiling in the AppBuilder.
See this entry in the Progress Knowledge base
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
What I do: Publishing .Net 3.5 application via VS, or msbuild (whatever), and now I need to insert to the published application separate directory (Modules - not added as a reference to the project - our project architecture does not allow this). So I'm copying the folder to published location then runs mageUI.exe select the application manifest and then the problems starts. As I press the populate button it's adding also hidden directory? So I remove the directory, after I want to save the manifest file I get the
"Warning MSB3110: Assembly 'NAME.Shell.application.deploy' has mismatched identity 'NAME.Shell.application', expected file name: 'NAME.Shell.application.application'".
Did you have the same problems, according to http://smartclient.codeplex.com/Project/Download/FileDownload.aspx?DownloadId=5060 it should be easy as 1-2-3 but it's not.
On the irony side, I am currently updating the SCSF documentation for ClickOnce deployment for .NET 4.0, and now I know exactly what the problem it.
First, you want to publish to a disk location, not directly to the webserver. So do that, and then copy the dll's you want to add to the deployment into the version folder with the application manifest (.manifest). Rename them yourself -- just add .deploy on the end.
Bring up MageUI and open the application manifest in that folder, then uncheck the box that says "add .deploy to the file names". Click "populate".
Then remove the deployment manifest from the list; it's called something like appname.application. You don't want it to be included in the manifest's list of files.
Now you can save and sign the application manifest. Then without exiting mageUI, open the deployment manifest that is in the root folder (NOT the one in the version folder). Click on "Application Reference", then click Select Manifest. Dig down to the application manifest in the version folder that you just signed and select it. Then just save and sign the deployment manifest. It puts a relative path in there, so if you modify the .application file in the version folder, it won't work right when deployed.
Now take that .application file from the root folder and copy it into the version folder (replacing the one that's there) so you have the right copy for that version in case you need it later.
Now copy the whole shebang out to the webserver. it should work.
I think you are saying you need to add a folder of stuff to your ClickOnce deployment? What exactly are you adding? You say modules -- are they going to be compiled in, or is it something else?
If you want to add files to the deployment you have already created, you need to use MageUI to edit the application manifest, which is called something like appname.exe.manifest. (The appname.application is actually called the deployment manifest, which is confusing but true.) After adding the files, you will need to re-sign the deployment manifest as well (assuming you signed it in the first place).
It would be easier just to add what you want included to your project and re-publish. Depending on what it is, you can set the build action to 'content' (jpegs, html, etc) or 'none' (dll's) and then set "copy to output directory" to true, and it will include it in your deployment.
I'm not sure exactly what you are including. Give me more info, and I can provide more specific help.
RobinDotNet