I've installed Drupal8 locally using Acquia Dev Desktop interface.
I've got error as below in Reports/Status Report:
Configuration directories Not present
Your sites/drupal-8-2-6.dd/settings.php file must define the $config_directories variable as an array containing the names of directories in which configuration files can be found. It must contain a sync key.
I also could not push to Cloud Dev(internet interface) because it shows error as below:
Requirement Problem:
Configuration directories Not present
Your /settings.php file must define the $config_directories variable as an array containing the names of directories in which configuration files can be found. It must contain a sync key.
My setting.php is under ~/Documents/DRUPAL/drupal-8.2.6/sites/default/settings.php
Should I make changings in this file?
What changes need to make to get rid from error?
thanks.
Precise detailed steps for the user6781412 solution at:
https://www.drupal.org/node/2891394
===
#user6781412 : Thanks
I detailed your solution in precise detail for newbies like myself, but this bloody forum keeps regecting it on the grounds that "Your post appears to contain code, blah, blah, blah."
I gave up after about an additional half-hour trying to format my solution for this site, and have instead posted it at the above URL at drupal.org.
You da' one. Peace out.
"All the best; intended."
Christopher James Francis Rodgers
I've solved the problem and fixed error by creating sync dir. outside of my root. So in this case I've created sync.dir under ~/Documents/DRUPAL and left it empty.
Then I've created code that pointing to this dir as below:
$config_directories = array(
// REPLACE THIS PATH for your path
CONFIG_SYNC_DIRECTORY => '~/Documents/DRUPAL/drupal_sync',
);
This fixed error.
Short history of sync directory:
"Sync directory contains configuration files that help move your site from your local development machines to the production servers. In the past, all configuration was contained in the database and moving from development to production was very troublesome".
Related
VS2017, SDK/WDK, C++ project
we have a c++ solution (driver) that is shared across developers via Team Foundation Services - visualstudio.com (now called azure devops?).
When I perform a get latest source code, and want to rebuild the solution I get two MSB3030 errors:
"Could not copy the file "C:\path of my colleague his file" because it was not found."
I found it strange that I saw on one of the two errors a path of my colleague his pc. He works on C:\ I'm working on E:\
Unloading the project, I saw he path being set here:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<PackageRelativeDirectory>
</PackageRelativeDirectory>
</FilesToPackage>
We cannot get this solution to build because of the MSB3030. First we have to clean the specific projects individually, rebuild it, then build another project etc.. a few steps to perform manually in the correct order , trial and error, drinking coffee, throwing bananas to the pc and praying that a monkey outputs the code correctly.
Has anyone seen somehting similar regarding MSB3030 errors?
On my pc I see the path of my colleague, but he doesn't see my path (strange!).
C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets(1699,5): error MSB3030:
Could not copy the file 'C:...' because it was not found.
I've set the Any CPU to x64 because it doesn't make any sense for c++.
C++ Windows Driver MSB3030 could not copy the file '' because it was not found
The reason for this issue is that the path of the ItemGroup is an absolute path in the project file:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" ...>
...
</FilesToPackage>
</ItemGroup>
Regardless of whether your colleague has added this file to source control, when you pull the code from the TFS server to your local and put the code in a different local folder, the absolute path will bring you a lot of trouble, you need to manually check the code on the TFS server for this file and you need to modify the absolute path of this file in your project. But this problem will reappear after your colleague updates after you submit your code. Because an absolute path cannot be assigned to two different paths C:\ and E:\.
To resolve this issue, you need to change the absolute path to a relative path in the source code. Generally, we prefer to add this file to the Solution/Project folder, then use the MSBuild Macros $(SolutionDir)/$(ProjectDir) to specify it.
Check Common macros for build commands and properties for some more details.
Hope this helps.
I'm just simply trying to open up a VS 2017 project. When I open the solution, I get the following error message:
Creation of the virtual directory http://localhost:58051/failed with the error: Filename: \?\C:\Users\Visual Studio 2017\Projects\Testing\Version 2.0.vs\config\applicationhost.config Error: Cannot write configuration file
I've checked the folders along the file path and they are not encrypted. All the folders along the file path have a black box for the Read Only attribute. When I go to the config folder and clear out the black box for the Read Only attribute and Apply the setting, I find if I exit and go back to the same folder, the black box reappears for the Read Only attribute. I've read that the black box doesn't really mean the Read Only attribute has been turned on. If the Read Only attribute was actually turned on, I should expect to see a check mark instead. However, this doesn't explain why I can't open the solution.
After I click the OK Button to the VS Error message, VS just says the solution is "(unavailable)" in the Solution Explorer.
Any help would be greatly appreciated.
I too had this problem with my project files located on OneDrive. The way I resolved it was I renamed the applicationhost.config file located in the ".vs\config" directory of your root project directory then reloaded the web project. This will create a new applicationhost.config file.
I had the same error message sharing a project between 2 machines via OneDrive and fixed it as follows:
1 - Closed VS.Net
2 - Opened [myappnamefolder].vs\config\applicationhost.config in Notepad
3 - Searched the open file for the filename in my error message (In your case C:\Users\Visual Studio 2017\Projects\Testing\Version 2.0.vs\config\applicationhost.config ).
It was found under system.applicationHost, sites, site name, application path, virtualDirectory - physicalPath
4 - Amended the physicalPath value to point to the valid path of the project's config file as above.
5 - Saved the applicationhost.config file
My paths were different because I had different home user directories on each machine. (User A & User B)
I have resolved this error with this way mention as below:
STEP 1:
Go to on that path
C:\Users\navz\OneDrive\Documents\IISExpress\config
STEP2:
When you reach on this folder "config"
in this folder we can see "applicationhost" file
STEP3:
Close the Visual studio existing project and delete the applicationhost file(see on Step 2 path)
Then open the existing project again, it will be reloaded automatically and work properly.
Had same problem then looked into vs\config\applicationhost.config and it was encrypted. I unencrypted file and solution loaded with no problems.
I've had this problem several times using VS 2017 with Onedrive. Resolved it by renaming the application.config and having VS recreate it. Just as well could have edited line in the file. See the Diff below as an example.
The config file is located in something like C:\Code\MyProject\.vs\config\.
I just encountered this error. I followed the steps in this answer: https://stackoverflow.com/a/50508207/1166163
When I tried to save my changes I realised TFS had marked the file as read-only, preventing VS from updating the value. Removing the read-only attribute fixed the problem.
None of the above worked for me. I ended up deleting and recloning the repo that was giving me problems. It then opened up just fine.
Windows 10 Defender was causing this for me. When I disabled control folder access it worked again. Odd, because it had been working with that setting on for a while.
my drives were different - but the main codebase was shared between the two machines - so on one it was in the d drive - so i mapped the parent subdirectory on the second machine to be the d drive ... which resulted in the same paths then on both ... i just had to open the solution from the d drive on the second machine
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
I have a bucket with more than ten thousand files. I am getting the following error while doing 'ls -l' folder but working fine for less than 1000 files in the folder. Any suggestions?
ls: reading directory ./: Input/output error
I notice that each listing of a file in folder makes an http call to S3, any chance this # can be increased?
Thanks!
I would like to recommend to take a look at the new project RioFS (Userspace S3 filesystem): https://github.com/skoobe/riofs.
This project is “s3fs” alternative, the main advantages comparing to “s3fs” are: simplicity, the speed of operations and bugs-free code. Currently the project is in the “testing” state, but it's been running on several high-loaded fileservers for quite some time.
We are seeking for more people to join our project and help with the testing. From our side we offer quick bugs fix and will listen to your requests to add new features.
RioFS should work fine with such great number of files per directory, but please try to increase the directory caching timeout in the configuration file (see dir_cache_max_time description in riofs.conf.xml)
Hope it helps you and we are looking forward to seeing you joined our community !
I have a django project that I have been working on as a solo developer, and have been using TortoiseSVN to keep the code managed in a repository on a work server. I work on this on a local installation of django etc.
There is now a second person who will be working on this project, and the possibility of working on some other PCs.
Now, there should, for the time being, only be one development version (branch?) of this project, but the configuration file (settings.py) will need to be different on each computer that is being used. I want to create one local version of this file on each PC which should not need to be changed again.
How can I set the repository (preferably within TortoiseSVN) to exclude this one file? E.g. the repository should not include settings.py. When a checkout occurs, it should update all files in the local folder but not change/remove the local copy of settings.py. When a commit occurs, settings.py should be ignored and not uploaded.
At the moment settings.py is overwritten/updated as per any other file in the project folder/repository.
Any nudges in the right direction would be useful - I'm new to SVN generally and would like to know if this is something that's going to need detailed understanding of branching or if there is a simpler way.
Thanks
In TortoiseSVN, when you try to commit your files, in the file list dialog, right click the file and look for the Ignore option. You can ignore by complete filename or extension.
If the file is already in the repository, and you want to remove it from there and ignore it, you can simply right-click the file and in the TortoiseSVN menu look for the 'Delete and add to ignore list' option.
You'll be looking for the svn:ignore property, which tells subversion to not version files matching a pattern or patterns you specify.
There's some guidance on using it with TortoiseSVN at:
http://arcware.net/tortoisesvn-global-ignore-pattern-vs-svn-ignore/
These should help:
I have a file in my project that every developer must change, but I don't want those local mods to ever be committed. How can I make 'svn commit' ignore the file?
Excluding Items from the Commit List
The typical solution is to do what bgever said and ignore the settings file itself, and then commit a file with example values, something like settings.py.example. That file should only be updated when you add or remove settings. When deploying, you'd copy that to settings.py and edit the values.