I have a 3rd party library which loads configuration from app.config
Now I want to configure it via Azure Service Fabric
Using the standard settings.xml will require a lot of work.
Instead I'm hoping to simply copy the old app.config into the SF Config folder and load configuration from there.
Basically the only thing I could not figure out is how to know the path of where the Config/* contents will be while running in SF.
I can get Context.CodePackageActivationContext.WorkDirectory
However, then the path from that is
..\MyClass.ServicePkg.Config.1.0.0\app.config
Is there a path I can query on the Context somehow to get full path to config folder?
Yeah you can get the absolute path to your Code and Config packages, substituting the names of your packages ("Code" and "Config" are the default names in the Visual Studio project templates):
string codePackagePath = this.Context.CodePackageActivationContext.GetCodePackageObject("Code").Path;
string configPackagePath = this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config").Path;
Some background info on service packaging here.
tl;dr:
Services are composed of "code" packages (your executables and DLLs) and "config" packages (any arbitrary configuration file or the built-in Settings.xml). Packages can be versioned and upgraded independently of each other. You can see this in Service Fabric Explorer under the "Details" tab of an application type (note the "Name" field - you can use any name you want and that's the name you put in GetCodePackageObject()).
Related
I am using Azure Devops in my project which means my SSIS project is stored in a file location that looks like this: C:\Users\johan\source\repos\Data Warehouse\Scripts. We are using the Project Deployment model.
In Visual Studio configuration manager I would like to make the DEV configuration dependent on the user. So for André this would change into C:\Users\andre\source\repos\Data Warehouse\Scripts and for Kasper into C:\Users\kasper\source\repos\Data Warehouse\Scripts. This would allow developers to run a changed script directly from Visual Studio. I could also have a fixed folder with scripts somewhere, but in that case a developer must copy his changed script to this folder to make it work.
I know parameters can't be variable but is there any other way to make this location dependent on the current user? These scripts are for example Powershell scripts that are executed from a package.
I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).
I would like to setup PhpUnit in PhpStorm. I press 1. Edit Configurations... and would like to enter this parameter in field 2.
I am using phpunit.xml as configuration file and all want to use a relative path like:
phpunit.xml
or use project root variable like
$PROJECT_ROOT/phpunit.xml
But both options are not working for me.
Based on your screenshot (the place where you want to use it): use full path -- in project settings such path is stored relative to the project root anyway (unless you specify some file which is outside of the project, of course) and the full path then reconstructed when needed (e.g. when shown to you or when used as a parameter during tests execution).
I don't think you'll be able to achieve what you want via the project's Run/Debug configurations. What might help you is the Default configuration file setting in your default project settings, which can be used to define the PHPUnit configuration file to use by default, so you don't need to specify it via the Use alternative configuration file option in your Run/Debug configuration.
To set this, open your Default Settings window, then navigate to Languages & Frameworks -> PHP -> PHPUnit. In the Test Runner section tick the Default configuration file checkbox and specify the location where you keep your configuration file. If this file will always be in the same path relative to your project root, you can use the $PROJECT_DIR$ variable to define the project root. So if your PHPUnit configuration file is always in the root of your project, you might set this to something like $PROJECT_DIR$/phpunit.xml. When you create a new project, its Default configuration file variable will be set to the file offset from your project root, and you won't need to use the Use alternative configuration file option in your Run/Debug configuration.
If you're opening the same project in different locations on the same machine this should work for new projects without any problem, if you want to share this configuration across machines, you might need to try PHPStorm's Exporting and Importing Settings functionality.
I'm not sure if this directly solves your problem, and it's a few months late anyway, but maybe this will be useful for someone else who stumbles across this question... The above instructions were correct for my 8.0.3 installation on Linux.
I am using SonarQube 4.0 . I try to created a project and run sonar-runner successfully I could see most metrics there.
But when I try to add widgets for LCOM4, RFC and Package design (to show the package tangle index), it shows "No data".
I am not sure what's wrong with my configuration, should I turn on some configuration or install some additional plugins to show LCOM4, RFC and Package tangle index?
I am running sonar-runner on plain file folder (not from SCM , didn't have POM file) , not certain if this is the cause.
If anyone has idea about this problem?
You must analyze .class files.
If you have not already done it, here is the parameter to add to your analysis configuration
# Comma-separated paths to directories with binaries (optional), in case of Java - directories with class files
sonar.binaries=build/classes
I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.