We have a problem with our azure build such that we can only get it to work if we use absolute paths in the WebRole/Contents/Content/SourceDirectory sections of our csdef file. Although it does support relative paths (including '..') and environment variables (! Yes as in SET) the problem is we cant get any non-absolute path to successfully build because it appears the .csdef file is "validated" twice: once where it sits in the project directory before packaging, and once again after it had been moved to the /bin folder. Obviously there is no one relative path that will be able to resolve to the same content directories if we start in two separate places! What you can do is get the paths right for ONE of the two build steps phases... but then it will fail on the other. The offending target is PreValidateServiceModel which calls the ValidateServiceFiles task.
In order to make my project build using relative paths i need to disable the PreValidateServiceModel target. The packaging appears to work although I'm worried some vital process is being missed by skipping the targets (aside from the obvious... the service files are not validated!). That said the .csdef file is still "validated" in the sense it has to be parsed to create the package.
I had a similar problem. Checking the documentation on the Source directory element of the WebRole schema, I saw that environment variable expension in the directory path is supported. This led me to the following solution.
In a pre-build event of the project containing the csdef file, I copy my files from the UpdaterFiles directory to a directory under the Temp directory:
IF NOT EXIST %TEMP%\UpdaterFiles MKDIR %TEMP%\UpdaterFiles
XCOPY $(ProjectDir)..\UpdaterFiles\*.* %TEMP%\UpdaterFiles\ /Y
Then my source directory just becomes:
<SourceDirectory path="%TEMP%\UpdaterFiles" />
The above works like a charm
Here is a different solution, which avoids copying to temp.
As already mentioned, the problem is that the relative path does not work from two different places:
1. ProjectFolder\ServiceDefinition.csdef
2. ProjectFolder\bin\Debug\ServiceDefinition.csdef
So I moved the source location of ServiceDefinition.csdef down two folder levels, so that the same relative path will work in both cases:
1. ProjectFolder\Service\Definition\ServiceDefinition.csdef
2. ProjectFolder\bin\Debug\ServiceDefinition.csdef
To do this, I edited the project file (right click, 'Edit Project File') and changed:
<ServiceDefinition Include="ServiceDefinition.csdef" />
into:
<ServiceDefinition Include="Service\Definition\ServiceDefinition.csdef" />
I created those two sub-folders in Windows Explorer and moved the file to its new location. Then I reloaded the project.
I noticed that Visual Studio automatically added these two lines for me:
<Folder Include="Service\" />
<Folder Include="Service\Definition\" />
In my ServiceDefinition.csdef file, I refer to the source directory by going up three folders to the solution folder, and then navigating from there:
<SourceDirectory path="..\..\..\MySourceProject\MySourceFolder" />
Related
In RubyMine, I have a project with many subfolders, each of which contains:
One or more standalone single-file executable Ruby programs (.rb files);
An input text file.
In older versions of RubyMine, when running one of the standalone executable programs (via Cmd+Shift+R on my Mac), the default folder in which RubyMine would look for the input file would be the same directory as the .rb file currently being executed -- which worked great.
The code used to read the file is something like:
data = File.readlines('input.txt')
However, after recently updating RubyMine to v2022.3.1, the behavior has changed, such that RubyMines now seems to be looking in the project's root directory for the file, instead of the same subdirectory as the .rb file currently being run. This produces the error:
in `readlines': No such file or directory # rb_sysopen - input.txt (Errno::ENOENT)
To correct this, I've been going into Run (menu) > Edit Configurations; and in the Edit Configurations dialog, in the configuration that RubyMine auto-created for the current executable file, changing the Working Directory value from the default of the project's root directory, to the subfolder of the current .rb file.
However, this above workaround is annoying, since I need to do it once each for every individual one of the many individual .rb executable files in my project.
My question: How can I configure my project and/or RubyMine itself to go back to the older behavior of defaulting a given .rb file to use its own directory as the default Working Directory, instead of the project's root directory?
(This question and/or its solution might also apply to other JetBrains IDEs such as IntelliJ, since they all seem to work similarly.)
The previous behaviour has been changed with https://youtrack.jetbrains.com/issue/RUBY-29236. So now yes, the logic is the following:
in case of no Ruby module, project's root will be used
in case of Rails, its home folder
otherwise the module's root
There is no option to change it in RubyMine but you can configure the configuration template using some variable there as Working directory.
I'm porting a large project to linux. I wrote all the CMakeLists.txt files, and everything compiles in my machine.
For whatever reason we still use TFS. The old version, not git with TFS.
I'm working in my own branch, but that branch has no build definition for linux. Before I check in, I want to be sure that everything compiles on the server too. So I need to merge my branch to another one, and submit that shelve set to the build job.
In my machine everything compiles fine. But when I run the build in the server, applying a shelveset to the branch that has a linux build definition, I get an error from the build, saying
CMake Error at
/myproject/subproject/CMakeLists.txt:165 (add_library):
Cannot find source file:
/myproject/subproject/IInternalTransactionManager.h
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
Indeed, that file is not there. Cmake complains about the file not being in the sources directory, which is true, because it is in another directory. But the fact is that I'm not asking for it either! My CMakeFiles.txt file does not include that file. That file is a header which is used in a few files, contains only classes definitions (no implementations), and the directory in which myHeader.h resides has been defined in include_directories. My CMakeLists.txt looks something like this:
set(PROJECT_NAME project)
project(${PROJECT_NAME})
include_directories(
../_include
)
set(source_files
main.cpp
file_that_includes_myHeader.cpp
)
add_library( ${PROJECT_NAME} STATIC ${source_files} )
and my file structure is something like:
/myproject/subproject/main.cpp
/myproject/subproject/file_that_includes_myHeader.cpp
/myproject/subproject/CMakeLists.txt
/myproject/_include/myHeader.h
So, why should cmake complaining about a missing file, if such file is not included in the CMakeLists.txt file? And why would this happen only the build in TFS? My guess is that there is something wrong when applying the shelvetset and is not related to my code, but I cannot prove it.
I compared the code after the shelveset is applyied, and still in that version the CMakeLists.txt does not mention myHeader.h
Or, there is some rule about including headers in CMakeLists.txt files which I'm not aware of.
So, after expending too much debuging I contacted the team in charge of the build process. And as it turns out, the building process in the TFS building definition was definetly NOT what I expected. And of course this was not documented.
Our development is mostly in windows (by far). The linux build has a step before building: a script is launched which parses each Visual Studio project file, gets the included files, and substitutes the source files in the CMakeLists.txt files with the one parsed from VS. Right or wrong, is just the way it is.
I could build the linux build in my local machine because everything was done correctly. The windows build worked too, even though the VS project files sometimes included some files which were not in the source directory but in some header only directory, and somehow that compiled. I guess because the directory was defined in the include directory. But When the CMakeLists.txt files were updated, cmake complained (rightly so) about not finding the files.
So, if anybody experiences similar issues, contact your devops team or whoever is in charge of such things.
Whats the proper way to form relative file path/ or file path for the runsettings parameter
<SettingsFile>xxxxxAutomation.testsettings</SettingsFile>
In my local environment this works but when i push it to build release agents it fails since
its looking for the file in a different directory which is my release folder
but instead its looking for this file in what appears to be in a folder directory.
This is the directory its looking at E:\Agent_work\r10\a\xxxxxxxxx.testsettings,
here is my current way i have it set
<SettingsFile>xxxxxAutomation.testsettings</SettingsFile>
here is the error message
Error: The test settings file E:\Agent_work\r10\a\xxxxxxxxxx.testsettings, specified in the MSTestAdapter settings, is not available. Either access to the file is denied or the file does not exist. Ensure that the test settings file is available and try again.
instead of
E:\Agent_work\r10\a_XXXXX CI Build\drop\XXXXX_Automation_Test\bin\Release\xxxxxxxxx.testsettings
There is no documentation that states how to formulate the file path on msdn and didn't see
anything online.
I suggest you can add a Copy Files task to copy the missing file from .../bin/release folder(Use the browse option) to default working directory:
I suggest you resolve this issue via modifying your pipeline instead of settings file, so that you can also work well locally with the unchanged runsettings file.
In addition: Clean Target Folder input should be disabled(unchecked) cause our target folder is the default working folder. Deleting all files in that folder would cause unexpected issues.
I am using cspack command to create cspkg as part of build. The command that I am using is
cspack.exe D:\StoreSimplePortal\StorSimple-Portal\src\StorSimple.CloudService\ServiceDefinition.csdef /out:StorSimple.CloudService.cspkg /role:StorSimpleExtension;D:\StoreSimplePortal\StorSimple-Portal\out\debug-AMD64\StorSimpleExtension /sitePhysicalDirectories:StorSimpleExtension;Web;D:\StoreSimplePortal\StorSimple-Portal\out\debug-AMD64\StorSimpleExtension /rolePropertiesFile:StorSimpleExtension;D:\StoreSimplePortal\StorSimple-Portal\src\StorSimple.CloudService\RoleProperties.txt
The build succeeds but /sitesroot folder is not created. Am I missing something here.
Can you verify that the sitesroot is in the StorSimpleExtension directory? If it is not, verify that it is included in the .csproj file.
The problem seems to occur when the site physical directory parameter is too similar to the role path parameter. Try altering the path parameter to:
/sitePhysicalDirectories:StorSimpleExtension;Web;D:\StoreSimplePortal\StorSimple-Portal\out\debug-AMD64\storSimpleExtension\
Note the added '\' and lowercase directory name.
See this question for more details:
https://social.msdn.microsoft.com/Forums/azure/en-US/014ce124-5ca6-46ce-b1ea-3d677a092f65/azure-sdk-16-cspack-command-line-tool?forum=windowsazuredevelopment
I am getting kind of frustrated with cmake, as I am trying to learn it and use it properly.
Here is my setup:
I have a directory called ~/project. In this directory, I have:
build directory
source directory
includes directory.
CMakeLists.txt file.
The contents of this CMakeLists.txt file is:
cmake_minimum_required(VERSION 2.8)
project(myProject)
subdirs(source)
I also have another CMakeLists.txt in ~/project/source, and its content is:
cmake_minimum_required(VERSION 2.8)
include_directories("~/project/includes")
add_executable(exec entry.cpp)
Now, I go into the build directory which is empty, and do cmake ... This works fine. However I then see a 'source' directory get created as shown here.
Why is this being created? I do not know what is going on. As I understand it, it should not be doing this, it should give me everything I see here, except for the 'source' directory.
Thanks.
Inside your build directory, CMake re-creates the whole directory structure of your project. The rational is, to keep the project structure. Image a bigger project with several levels of subfolders and sources, libraries and tests scattered in a meaningful way. To run a test, you follow the structure where the test's source is located, just in the build directory instead of the source directory.
As your project, at least as far as CMake knows it, is only the source subdirectory, only this folder is created.
If you really have just the source project, I am not sure whether would be better to place the CMake project just inside source.