Considering a project in Visual Studio with the following structure
Project
---Folder A
----- CS Files
---Folder B
----- CS Files
---Folder C
----- CS Files
All works great but I want to pack only content from Folder A and C, ignoring totally all .cs files from Folder B.
is that possible?
I tried the <file> and <contentFile> arguments in a nuspec file but that doesn't quite work.
<file> only added them as a extra file in the package and <contentFile> had no effect
How about this two lines
<file src="Folder A\*.cs" target="content\Folder A" />
<file src="Folder C\*.cs" target="content\Folder A" />
I had a similar problem and could use "exclude" to excluse all Tests.dll from my deployed dlls. But actually I do not know how to use it right to exclude the folder
Hope that helps
Related
Running the command nuget.exe pack <path-to-nuspec> -NoDefaultExcludes -OutputDirectory <path-to-output-dir> on a Windows 10 machine does not include files without a dot, such as "Dockerfile". I have not been able to find any information on this, apart from information on how to include files starting with a dot.
Is it working as intended or am I missing some option? Seems like a strange limitation, gives that Dockerfile is something one might want to include in a nuget package.
I found a work-around for this. In the .nuspec file, just replace
<file src="include/**/*.*" target="include" />
with
<file src="include/**/*" target="include" />
It seems that '*' catches the "*.*" files as well.
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.
I'm scanning an Elixir project by reading the mix.lock file and parsing the output of mix deps.tree command. Later on I need to locate each dependency's .tar file. On my windows machine the location is inside the C:\Users\{user-name}\.hex\packages\hexpm folder.
However on my linux machine, the .hex folder contains only cache.ets file, but no packages folder. Searching for .tar files returns nothing relevant.
Any idea where are those files hiding?
cheers,
eRez
Should be under in your home: ~/.hex
But the archives seems to be located in ~/.mix/archives/
For example, if I try to upgrade my hex:
~ > mix local.hex
Found existing entry: /home/meox/.mix/archives/hex-0.18.1
You can find that on ~/.hex/packages/hexpm.
apparently the project on which a ran my tests was the first hex project on that machine, and running the mix deps.get didn't result any .tar files in the cache as expected, but when i switched to a different project all was back to normal and indeed everything as under ~/.hex/packages/hexpm
I am new to geb testing. We have two project folders. One of them is a subset of others. During last few days, whenever I check the status of the subset project folder using git shell, lot of closure.class files are showing as changed. But I am changing only the groovy files. I am not sure why this is happening? previously I haven't seen anything like this.
Also lot of class files are showing as untracked files.
The file name look like this.
xxx$_$spock_feature_7_29_closure6.class
We are using IntelliJ IDE.
There are lots of files, I mean class files generated when you try to build using gradlew. As Peter had suggested already, create a .gitignore file and add anything you want to ignore, for instance:
*.log
build
.gradle
.DS_Store
*.ipr
*.iml
*.iws
out
*.pem
gradle.properties
and run the gradlew clean command. You will not see those anymore. Cheers!
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" />