I copied a web.config that already has show cheetah transforms defined from one project to another. The transforms show up in the new project just fine, and I can edit them. However, they are not being applied when I run the project.
How can I fix that?
The project itself must be configured to apply transforms.
To do that, in the new project:
Right-click web.config (or whichever file has the transforms)
Add Transform
This will setup the project to apply Slow Cheetah transforms, and will leave the copied / edited transforms in place.
This action may take a moment because the project is unloaded, modified, and re-loaded.
Related
I've successfully imported a *.bprelease file to my Blue Prism environment, but the contents are not visible in processes list.
What can I/should I do to have the contents of the package appear in the list after importing?
This problem lies in a bug in new version of Blue Prism. It is actually quite common, I've seen this happen for a few people in my team. There are two things needed to know to fully understand the problem:
Since 6.3 (the multi-team env. upgrade) when you import an object/process that is not in a group, it will be added to a new group called 'Default'
Blue Prism will not allow you to manually add a group with the name of an existing group (under the same parent group)
If a group with a duplicate name gets created anyway (by an import or by DB command), one of the groups will not be displayed
And that is what happened here.
The easiest thing to resolve this problem is to simply rename the 'Default' folder you see to something else and then refresh the view (hit F5). You should see a new folder pop-up, with your invisible objects.
Alternatively, you could achieve the same results with a couple of SQL scripts, but this is much quicker.
Sometimes even renaming the default folder does not work.
It is because there is a previous object (for example) with the same name, but not assigned to any folder.
We have solved the issue importing the object alone, and chosing "renaming the previous version" option instead of overwriting. So, the object is properly imported and placed in the Default folder, from where you can move it to the right one
We have Installshield 2009 for our product. I am trying to muddle my way through it to make some updates (obviously, I am not the original author).
Within, there is a fairly complex arrangement of components and files, plus, there is a script section for some custom work.
I need to accomplish the following, without creating a blank object in the repository.
One of the components needs to create a directory tree (two folders deep).
Within that tree (deepest folder), I need to create a blank file.
Questions:
Do I need to create two components, one for each directory level, or will the tree be created if I specify [INSTALLDIR]folder1\folder2?
I am thinking that the installscript would be the place to create the empty file, based on the CreateFile example in the help. I notice that, in the components page, that, once I typed the value for the Destination property, that a little "tag" of sorts appeared at the start {FOLDER2}. Can I used that tag as an argument to CreateFile and how would I reference it?
Regardless of the project type, I would probably suggest creating the folder structure in the Files and Folders view, and adding the empty file there. It's just simple and you'd be done with fewer chances of error.
As to the questions you asked, neither Basic MSI nor InstallScript projects require components for every folder level on the system. Note that if the folder isn't already there when it executes, the CreateFile approach is unlikely to create the folders for you.
In a Basic MSI project, {FOLDER2} indicates that FOLDER2 is the name of the directory entry, and after CostFinalize there will be a property of the same name that contains its run-time location. You can retrieve it in an InstallScript custom action with MsiGetProperty. In a pure InstallScript project the approach would be a little different, worst case it would be something like TARGETDIR ^ "folder1" ^ "folder2" (my InstallScript is rusty).
We are starting a new project using angular2, typescript and gulp. For the time being our application will consist of two subprojects: a components library (which in the future might be spun off into a separate project) and the app using the component library.
The layouts of the project is going to be something along the lines:
/project_root
/component_library
/src
/library
/components
/services
... etc
/application
/src
/app_name
/components
/services
... etc
The components in application will be using components from the library (but not the other way round)
We would like to have clean (non relative) imports in the app components when importing stuff from the library (we want to avoid ugly imports of the sort '../../../component_library/src/library ...etc' plus, what's more important, we want to be able to move the library code to a separate project without the need to update imports.
There are two possible solutions I see (don't like any of them):
Add a gulp task that would watch the component library and on every change copy the file to node_modules in /project_root
Some sort of simlink? so that we can point /project_root/node_modules to /project_root/component_library/src?
I'm afraid the first solution might not work well with IDE autocomplete in the application (first gulp would need to do the compilation/copying then the IDE would need to pick up the change from node_modules - this looks like something that can be really slow)
The second solution feels hacky - it would need to be repeated by everyone who checks out the code from repo.
What would be the best solution here?
what's more important, we want to be able to move the library code to a separate project without the need to update imports.
Ship your component_library with source and add it as a node_module dependency. Then when someone pulls your code they can add a git remote to node_modules/component_library code and work on the two projects seemlessly.
This is the approach I took with ntypescript.
Consider a solution has 2 projects: ProjectA and ProjectB (both are MonoTouch apps) and ProjectBase. ProjectBase contains the whole application, but Main.cs file (with the entry point) is located in ProjectA and ProjectB (which reference ProjectBase). This way, running any of A/B projects will boot up the application from ProjectBase.
Now, I want to override something for ProjectA only (it might be XIB file, image or a .NET class). Is there any way I can setup the solution so that the code and resources, produced by ProjectBase, are merged with the ones from ProjectA/ProjectB and the latter wins?
I found (probably a quirky and kinda-undefined-behavior-driven way) of overriding XIBs: I just put a XIB into ProjectA and ProjectB, name it the same as it was named in ProjectBase and them exclude it from ProjectBase. Although MonoDevelop compiles all items, it seems that the startup project's XIBs get priority, so that I see ProjectA-specific XIBs when I launch ProjectA and ProjectB-specific XIBs when I launch ProjectB. However, I am not sure it is the way it should behave, plus, from what I can see from build log, ALL projects get built yielding resources at the end.
P.S. I'm sorry if this has been asked previously, but I was not able to find the similar question on SO.
I was once trying to do this for a bunch of apps. I would have thought build order would be ProjectBase and then ProjectA, and the content copy system would be the same... Guess this means we are wrong.
You could do a few things.
A) Build your own program to copy resources which are marked for content. Would not be very hard, just need to read the .csproj files. XML parsing is easy enough in .NET. Run this program on post build. Would just have to be careful when doing builds such as to zip or to the device as I am not sure how it handles post-build events.
B) [This is what I did instead] If I expect to also make ProjectC, ProjectD ... ProjectN I instead made a program to generate my program... (Programception).
What it does, has ProjectBase, and ProjectTempalte. You enter your new project name into this program, say, "MyNewProject" and it will create the correct folder structure, write the correct csproj files, and update SLN file. ProjectTemplate has various placeholders in .csproj files like {PLACEHOLDER} which Programception would just go through and find/replace with my project name. Image files (and in your case XIB) are then only kept within ProjectA (B..C..N) unless I do not expect to try and override them in which case they would stay in ProjectBase. This is a lot easier with a XIBless application I would assume. I never use XIB's anyway.
Hope that helps!
Is there a way to reference the last build label of a particular project in CC.NET? I have a project set to execute a task that needs to run only when Force Build is clicked, but the path of the working directory changes based on the build number of our main trunk.
Currently I have a workaround where we set an environment variable to the value of %ccnetlabel%, but this seems like a dirty way to do it, and I am curious to know if there is a way to refernce the build label of a project directly.
We are running CC.NET 1.4.4.49.
I found out that with 1.4.4.49 there is not a way to reference another project's build label. I got around this by adding the following XML to the project configuration:
<labeller type="stateFileLabeller">
<project>Other-Project-To-Take-Build-Number-From</project>
</labeller>
What had happened was that once I figured out that %ccNetLabel% was actually the correct way to go about this, I tried just using it in this new project (we use %ccNetLabel% elsewhere which works fine). However, without specifying the labeller tag, %ccNetLabel% causes CC.NET to throw an exception saying that '%' was not expected.