Let's say I have a following folder structure
build
build.fsx
build.bat
//build tools etc.
src
Project1
Project2
//...
When I run my RestorePackages() in build.fsx it will look for packages.config in "./**/packages.config" (according to documentation), and will ignore all packages to be restored in project folders.
I can use this method and probably give path one-by-one to every project's packages.config, but I don't want to change build script every time I add new project to solution.
Is there a way, to make RestorePackages() to look for all packages.config in some specific path?
EDITED:
Additional, related question. I see, I'll have to pass nuget path to RestorePackage, because by default it seems to expect it in ./tools/nuget/nuget.exe. I can do this probably like that:
RestorePackage(fun p -> { p with ToolPath = "my/nuget/path"})
But I have no idea how to tie it into example you provided. F# syntax is still a little bit confusing for me around pipes and function calls.
I see two solutions.
put your build script into the project root
Overwrite the default method. Put this to the top of your build script:
let RestorePackages() =
!! "./../**/packages.config"
|> Seq.iter (RestorePackage id)
Related
We’re using Xunit for testing. We’re running our tests via the built-in Visual Studio 2013 Test Runner, using the Xunit plugin.
The issue is that some of the tests need to refer to files on the filesystem. It seems that Xunit (or the VS Test Runner—not sure which), copies the assembles, but not any supporting files in the bin directory, to another directory before executing the tests, hence our test files are not found. [The MS Testing framework specifies attributes for listing files to be copied, but Xunit does not.]
How to either disable this copying behaviour, or else programmatically determine the original bin/ directory location to fetch the files?
It seems that most proposed solutions (including on the Xunit bug-tracker site) suggest storing the files as embedded resources instead of ‘copy always’ files. However, this is not always practical, for example: testing file manipulation code, and (in one case) code which wants a Sqlite database file.
Okay, typical, just as soon as I post the question, I find the answer myself…
The gist is that the copying (Shadow Copying) of assemblies seems to be done by the .NET framework, not by Visual Studio or by Xunit.
We had been using Assembly.Location to locate the assembly file, and hence the test files. However, this was wrong, since it gave us the location of the Shadow-Copied assembles instead of the originals.
Instead you should use Assembly.CodeBase to fetch the base assembly code location. However, this is a (File) URL, so it’s necessary to extract the path from the URL. The new (C#) code looks like this:
var codeBaseUrl = new Uri(Assembly.GetExecutingAssembly().CodeBase);
var codeBasePath = Uri.UnescapeDataString(codeBaseUrl.AbsolutePath);
var dirPath = Path.GetDirectoryName(codeBasePath);
return Path.Combine(dirPath, relativePath);
…where relativePath is the path relative to the Bin\ directory.
After a bit of search I found the solution here: https://msdn.microsoft.com/en-us/library/ms182475.aspx.
Particularly, the first step has been enough for me:
If they are specific to one test project, include them as content files in the Visual Studio test project. Select them in Solution Explorer and set the Copy to Output property to Copy if Newer.
associated to the following code:
var filename = "./Resources/fake.pdf"
File.OpenRead(filename)
As of .NET5 (perhaps earlier), CodeBase no longer works, so the solution is now to copy all of your files to the bin directory first and use this as your known location.
What makes this OK now, which was always a total pain in the past, is that you can copy a directory to your bin folder easily from your csproj file.
<ItemGroup>
<None
Include="TestFiles\**"
CopyToOutputDirectory="PreserveNewest"
LinkBase="TestFiles\" />
</ItemGroup>
Where TestFiles is in the root of your project folder. Now you can access these files with the following helper method.
public static class TestUtils
{
public static string GetTestPath(string relativePath)
{
var codeBaseUrl = new Uri(Assembly.GetExecutingAssembly().Location);
var codeBasePath = Uri.UnescapeDataString(codeBaseUrl.AbsolutePath);
var dirPath = Path.GetDirectoryName(codeBasePath);
return Path.Combine(dirPath, "TestFiles", relativePath);
}
}
I am running .Net Core 1.0 on Mac. Assembly.GetExecutingAssembly is unavailable. I use the following code instead:
var location = typeof(YourClassName).GetTypeInfo().Assembly.Location;
var dirPath = Path.GetDirectoryName(location);
return Path.Combine(dirPath, relativePath);
relativePath is the path relative to the directory of your DLL.
After struggling with trying to identify directories and copy files (there seem to be multiple directories in play and it's hard to pin down the right one), I found that you can just turn off shadow copying; at that point the unit tests reference content in the bin/{configuration} folder again.
To do so, follow the directions here. It seems to be as simple as setting shadowCopy to false:
{
"shadowCopy": false
}
I'm unclear whether this setting has any adverse interactions with other settings (e.g. appDomain). If anyone knows, your comments would be welcome.
I have a pretty simple Go project that I'm trying to restructure so that it follows the normal Go project structure (and so I can run go build).
I currently have two source files, both with package main. All the files, including a few text configuration files that my program needs at runtime.
So right now, it looks like:
<project_name>
- main.go
- source2.go
- config_file.txt
I can run go build when I'm in this directory, and it creates one binary (named <project_name>. This works fine, but I'd like to set this up to better follow the Go standard package structure (specifically so that Intellij IDEA will recognize it as a valid project).
Right now, I have the entire <project_name> directory in Git, and I'd like to keep it that way.
I tried putting the source files in a folder called src, but then go build says there aren't any source files to compile.
How should I structure this?
EDIT:
Figured out the issue with putting stuff in src/: I need to run go build <project_name>.
I'm still wondering if there's a way to set up a project without a global GOPATH. I have all my projects under one folder, with a subfolder for each project (not all the projects are Go project). I'd like to keep that system.
What I want is:
projects/
- project 1/
- src/
- bin/
- pkg/
- project 2/
- src/
- bin/
- pkg/
Then I'd like to be able to run go build <project_name> (while I'm in that project's directory) and have it compile that project. Is that possible?
The "canonical" way to organize your Go code is described in How to Write Go Code. It is explained in a less formal way in this blog post. This concept is kind of contrary to what you have in mind - you have a workspace directory, specified by the GOPATH environment variable, and the source code of all projects resides in subdirectories of the "src" directory of the workspace. You can have multiple workspaces if you specify several directories in GOPATH.
I would suggest you give the "recommended" way to organize your code a chance, maybe it will grow on you. It may seem a bit unusual, but it has its advantages. If you find out you absolutely can't live with it, you can still work around it, e.g. by setting GOPATH dinamically in a script.
As for the Golang IDEA plugin, the last version I tried some time ago didn't yet support this project structure, but newer versions may have changed that. In fact, one of the plugin's authors (dlsniper) has added a comment to the above blog post giving examples of alternative project structures that still use a global GOPATH.
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
I am using Xcode as part of my build for OS X, but since it is not the only IDE used, files may be added from the file system directly.
As far as I can tell, there are two ways of adding folders:
Folder reference picks up all the changes on the file system but does not register any of the files as sources.
Recursive copy allows for the files to be built but I need to constantly maintain the file structure
I am wondering if there was a way to setup Xcode to build all of the files that are a part of the folder reference or failing that, if there is a quick script to automagically fix file system discrepancies.
I came up with proof-of-concept solution that works, but will require some work to use in production. Basically, I set up a new "External Target", which compiles all source files in a given directory into a static library. Then the static library is linked into the Main Application.
In detail:
Create a directory (lets call it 'Code') inside your project directory and put some source code in it.
Create a Makefile in the Code directory to compile the source into a static library. Mine looks like this.*****
Create an External Target (lets call it 'ExternalCode') and point it to the Code directory where your source and Makefile reside.
Build the ExternalCode and create a reference to the compiled static library (ExternalCode.a) in the Products area of your project. Get Info on the reference and change the Path Type to "Relative to Built Product".
Make sure ExternalCode.a is in the "Link With Binary Libraries" section of your main target.
Add the ExternalCode target as a dependency of your main target
Add the Code directory to your "User Header Search Paths" of your main target.
Now when you drop some source files into 'Code', Xcode should recompile everything. I created a demo project as a proof of concept. To see it work in, copy B.h/m from the 'tmp' directory into the 'Codes' directory.
*Caveats: The Makefile I provided is oversimplified. If you want to use it in a real project, you'll need to spend some time getting all the build flags correct. You'll have to decide whether it's worth it to manually manage the build process instead of letting Xcode handle most of the details for you. And watch out for paths with whitespace in them; Make does not handle them very well.
Xcode's AppleScript dictionary has the nouns and verbs required to do these tasks. Assuming your other IDE's build scripts know what files are added/deleted, you could write very simple AppleScripts to act as the glue. For example a script could take a parameter specifying a file to add to the current open project in Xcode. Another script could take a parameter to remove a file from the current project. Then your other IDE could just call these scripts like any other command line tool in your build script.
I'm not aware of any built-in functionality to accomplish this. If you need it to be automatic, your best option may be to write a Folder Action AppleScript and attach it to your project folder.
In all likelihood it would be a rather difficult (and probably fairly brittle) solution, though.
It's not pretty, and I think it only solves half your problem but... If you recursively copy, then quit xcode. Then you delete the folders, and replace them with simlinks to the original folders, you at least have files that are seen as code, and they are in the same files as the other IDE is looking at... You still will need to manually add and remove files.
I sort of doubt that there's a better way to do this without some form of scripting (like folder actions) because xcode allows you to have multiple targets in one project, so it's not going to know that you want to automatically include all of the files in any particular target. So, you're going to have to manually add each file to the current target each time anyway...
One way to import another file from add/existing file:
and set your customization for new file that added .
see this
I am building a project using Visual Studio. The project has a dependency on a lib file generated by another project. This project is there is the parent directory of the actual project I am building.
To be more clear,
I have a "ParentDir" which has two subDirectories Project1 and Project2 under it.
Now Project1 depends on lib generated by Project2.
In the properties of Project1, I am trying to give a relative path using
$(SolutionDir)/../ParentDir/Project2/Debug
But this does not seem to work.
Can you tell me where i am going wrong, or suggest the correct way of achieving this.
Add the dependant project to your solution and set it as a dependency of the other project using project properties. Then it just magically works ;).
A solution is just a file that describes a set of related (interconnected) projects and the relation between them, so this is the correct way of doing it.
Your current dir is your $(ProjectDir), that is where .vcproj file is.
So, just write ../Project2/Debug, that will do.
Even better, write ../Project2/$(ConfigurationName) for all configurations
thus you will be always linking to the correct version of that lib.
I think Visual Studio does not expand the relative path properly when the ".." is placed somewhere in the middle of the path string. It only knows how to expand ..{sub-path}.