I'm trying to find the exact path of where my SSIS packages are stored. The msdb.dbo.sysssispackages folder only shows a "folderid" and a "foldername". I'm looking for the direct path it's stored at.
Example, we house most of our ssis packages on a path such as this:
\\servername\d$\packages
Is there a way to get that path above using t-sql?
This might be an answer totally in the wrong direction, but cant you just look at your package path in your ssis-project?
I assume that \servername\d$\packages is just the folder where
your ssis-packages and project is.
Related
I am trying to determine how I can find what recipe a source file from the build/tmp/work directory came from. Basically normally most of the recipes in the source folder are uri. Then get downloaded and installed to various temp folders. I want to create a patch for some of the files, but I can't seem to figure out which files belong to what recipes.
Thank you
Run oe-pkgdata-util find-path /path/on/target/to/file. This will give you the package installing the file. From there, run oe-pkgdata-util lookup-recipe <pkg-name>, this will give you which recipe is creating the package. That should be enough to find out which recipe you need to modify. You then need to check whether the file you want to modify is part of the recipe (Yocto artifact) or part of the software that the recipe builds. For the former, you can override the file, for the latter, you can create a patch (you can use devtool to help you create the patch).
So I've tried everything that was advised such has updating Nuget, ticking nuget.org in Nuget Packege manager and I still get the error of:
Does anybody know what to do ? Thanks.
It looks like your project path is long enough that when the package is restore, restore the package folder fails because it reached the qualified name length limit. See the NuGet issue for this.
Could you try to move you project to root drive?
Move your project to a shorter path location (a root drive will be much better; Example: D:\) and have a try.
I am trying to read my local solution packages folder using NuGet.Core.
If I create new UnzippedPackageRepository(pathToPackages) and call GetPackages() on it, the result is empty. I am looking at the source of UnzippedPackageRepository and it has:
from file in FileSystem.GetFiles("", "*" + Constants.PackageExtension)
let packageName = Path.GetFileNameWithoutExtension(file)
where FileSystem.DirectoryExists(packageName)
select new UnzippedPackage(FileSystem, packageName)
So it seems to expect *.nupkg for each package in top level?
Anyway, what is right way to read solution package store aside from going through each folder and creating UnzippedPackage manually?
Solved it, solution packages folder is handled by SharedPackageRepository.
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 just setup hudson (CI), how do I tell this Dude that my NAnt.exe is not in the \bin folder?
it's keep looking for this path:
C:\myProjects\web2009\tools\nant\bin\NAnt.exe //doesn't exist
but in the reality I setup it, in here:
C:\myProjects\web2009\tools\nant\NAnt.exe // the correct path
Have you looked at the Hudson configuration page? It should be configurable there:
http://hudson:8080/configure
The Nant plugin has a wiki page which says in part:
In order to use this plugin, you need to first
configure a NAnt installation, which can be done on
the Hudson Configuration page. Simply specify a name
for the installation, and the path to the installation
directory.
The Wiki Page answer to simply specify a name and path is NOT enough.
It seems that the installation path for the NANT HOME makes an "assumption" that there is a further \bin folder where the actual EXE is located. We all know what happens when you make an assumption.
So, for example:
My nant was located in
C:\Code\Projects\Learning_Hudson\tools\nant
and I kept getting errors, even though that was the same path I used in my NANT HOME config value. But I did keep getting a "not a directory" error on my NANT HOME with the above path.
So, after searching for an answer, which I didn't find, I found this question and it helped me figure out to MOVE my nant files to a bin subdirectory.
C:\Code\Projects\Learning_Hudson\tools\nant\bin - is where I moved the nant files
and the I left the NANT_HOME configuration path as
C:\Code\Projects\Learning_Hudson\tools\nant
and that got ride of the errors, and I finally got a successful build after 12 attempts, and lots of configuration changes.
Hudson seems to expect NANT_HOME to point to a folder that contains a bin directory where nant.exe can be found.
This confused me as well at first, but I just moved my Nant\bin folder to the appropriate location to get Hudson to save the setting. (I'd imagine you can do the same thing to get your setup working.)