Can anyone tell me where I can find the TIBCO Business Studio *.tra configuration file?
I made small research and it turned out that this would be TIBCOBusinessStudio.ini
However, once I'll add my custom property, like user.timezone=UTC and I'll check in TIBCO Business Studio config (in Help-> Instalation info -> tab Configuration), I can see that my value is set there, but afterwards default value is set, like:
[...]
user.timezone=Europe/Belgrade
[...]
user.timezone=UTC
[...]
It sees that simply my value is overwritten from somewhere else.
What I can find the source of that setup?
Related
I am a Visual Studio noob. My background is more Unix-related and mostly used to building things via scons or make. I don't even have much Eclipse experience.
Anyway, I am frustrated how it seems very difficult to move files between projects in VS. (I am running Visual Studio 2013). For example, suppose I have a ProjectXRel (release) and I want a ProjectXDev (development). I want them both to be runnable, and the dev version might have just a few editing changes that differ it from the rel version.
The intuitive thought is to just copy the files from ProjectXRel to create ProjectXDev, but VS seems to fight me on that (it wants to rename all the namespaces to the title of the project).
Also, some of the files, like .cs files derived from .dbml via OR designer, seem uncopyable, and rely on one replicating the process of using the utility to having valid files. I'm used to a project being defined by its files, but that's not really the case in VS. Instead it seems defined by process steps used to create and organize the files.
Also, do serious developers just use command line calls and powershell? That's seems harder, but at least you know what the %#$$# is going on.....
So, the basic question is, how does one replicate an existing project to produce a similar one for development purposes? (I know source control such as git could help with that, but that's not an option for this situation.)
Thanks!
You should be using the same project for both Development and Release.
The things that are different between Development and Release should be stored in a config file (web.config or app.config, depending on what type of project).
You should then be using Configuration Transformations to transform that .config file into Development or Release.
In Visual Studio, right click on the project and click Add New Item, select "Application Configuration File".
In this file you can put connection strings or key/value pair settings in the AppSettings element (MSDN Link).
Once you have your basic settings defined, you can then right click on the config file and click Add Transformation. This will add transformations for each of the Project Configurations you have. (by default Debug and Release).
It will look like this:
Now you can build deployment packages.
Or install Slowchetah and then when you press F5 to debug it will run the selected project configuration with the configuration transformation applied.
I'm currently implementing a vsix extension tool window which will soon need a database connection string for querying some data to display to the developer in the tool window. I'd like to make this connection string configurable by the developer. As the developer is unlikely to change the config settings often a file would be sufficient.
Is it possible to just use an app.config file in the same folder as the sln file and if so must I use some custom configuration settings to wrap the file? NuGet seems to implement this approach but I don't fully understand the internal architecture to see how the config file is used.
I'd appreciate any alternative approaches too.
Edit:
I have since realised that the dynamic data the config store would serve must be solution specific so that a tool window used in one solution can use different properties to that of another solution. I guess one possibility would be to use the .settings file to store the location of a single config file that itself stores information related to different solutions.
The best place to store settings for a .vsix extension is to use a .settings file. In order to create one do the following
Right Click on the project and select "Properties"
Go to the Settings Tab
Click on the link to create a default settings file
This will create a couple of files in your solution.
Settings.settings
Settings.Designer.cs
Additionally it will bring up a designer from which new settings can be added. These can be accessed afterwards by using the Settings.Default static property
Been there and in my opinion the built-in mechanism works best, detailed walkthrough: http://msdn.microsoft.com/en-us/library/ff460144.aspx
Adding a note from self I can see that the underlying implementation uses system registry subkey. However after VSIX extension uninstalled all the keys are removed automatically so your extension is not polluting the system leaving orphaned entries.
I am moving now from VS 2005 to VS 2010 with products consisting of few solutions with numerous projects each. I wanted to make use of the property sheets system so our numerous configurations would be easier to maintain.
One of the issues is that we want to use Windows SDK 7.1 (as we need BaseClasses sample - and if we have to use that sample that why not the entire SDK)? But this requires me to change PlatformToolset on each and every single project in all the solutions. Also we will have to remember to change that value for newly added projects. Rather bad idea.
So I wanted to set this (among other things) from a custom property sheet. There is no such option directly from dialog shown when setting properties on property sheet. Adding entries manually to the XML file didn't help as well (but I haven't also seen any error or warning message).
Then how am I supposed to set default PlatformToolset value? At best in a configuration file which can be committed to repository. But if it could be done in some computer local settings then it would be acceptable too.
(Note that I know that I can use BaseClasses differently and avoid that problem at all but I think it is interesting issue in itself.)
I also asked this question at MSDN Formus.
PlatformToolset must be set in project properties at the begin of the file before inclusion of other files so that it can be later used to set up some defaults. If non is set then those inclusions will set it up to some default value.
Resetting it later even if works is pointless as everything was already included/set up. So to change the default value to a different SDK it seems VS configuration files (those which are included) should be changed appropriately.
But this does not have to be a good thing because it is local for the machine.
There is also an option of manual inclusion of property file which sets the PlatformToolset before default inclusions. However MS warns that if project file does not keep proper order (and this would spoil the order) VS GUI tools for project set up might not work properly.
In the end I just manually changed all projects. New projects also have to be changed to the new PlatformToolset.
In VS, it is possible to set a custom build rule at the individual file level. However, unless you change the description of the build step (which is what msbuild outputs when running the external tool), all you get is the default, which says "Performing Custom Build Step," followed by the error output of the tool.
I recently got burned by this in an inherited solution, where the build rule for a .asm file buried deep in a project was failing, and NASM didn't provide any useful debug information. Since I didn't know what file was failing, it took me forever to find the problem. One thing I tried was changing the description for all the projects in the solution (by selecting them all at once and opening the properties panel) and adding macros to show the project and file affected. Since the build rule was attached to a file, however, this naturally didn't work.
I also tried searching for the default description string in all the project files, but the project files don't store this information unless you set the value. So clearly, there's got to be a default somewhere. Anyone know how you can set this?
I doubt you can change the default for everything, but what you can do is create a property sheet in which you set a custom description, and than add that property sheet to all projects needing it.
We're creating an application that understands some command-line parameters. There are some default's we would like to supply on the command-line when debugging, and these are easily set in the project settings as explained here.
The thing is visual studio stores these settings in a *.csproj.user file, and the default settings for integrated source control do not check-in *.user files. We would like to just have these default command-line parameters in everyone's IDE when debugging this project.
Often (but not always) when visual studio guides you into doing things a certain way it is for good reason. We probably don't want to just check-in someone's .csproj.user file... right?
This question is has a few parts:
Why does Visual Studio store this
particular setting per user?
Is there a way to alter this behavior? - Would doing so bring bad juju?
Under these circumstances is it OK to check-in and share a .user file?
Is there a better way to accomplish what we are
trying to do here?
Thank you -
Maybe you could alter the program to optionally read its parameters from a configuration file as well as from the command-line (and then check-in a copy of that configuration file).
I would not recommend checking in the user file because, as you said, this is per user. If someone checks out your "default" user file and then makes any personalized configuration changes, those will be reflected back in the user file and (most likely) will be reflected in the source control.
If you want someone to set command-line parameters for debugging, I would adjust the project file to include these - don't include them in the user file. (It is okay to check in the .proj file, and I typically do for my team projects.)