Is there a way to find out the project path at compile time?
I want to create a unit test that tests if the configurartion in the default web.config (the one in the project folder). Mainly to reduce human error.
I cannot rely on assembly locations at runtime (for the test), so I need to know where the project folder is to access web.config there.
I need a "generic" solution since I'd like to use the same (base) test code for multiple projects, and the physical location is different anyway for most development machines.
Thanks.
Based on rkb's answer,
As it sounds like you've got a C# project, use this post build step.
echo namespace ProjectPath { static public class ProjectPath { public static readonly string Path = #"$(ProjectDir)";} } > $(ProjectDir)path.cs
Then include path.cs as an existing item to your test project. Then you can access it via:
string path = ProjectPath.ProjectPath.Path;
If you want the Visual Studio project path, at compile time, you could use a Pre-Build Event (see the Project Properties dialog) to run a command line that will create a source file used in your project.
The source file will contain some code, say a variable definition. Your testing code uses this variable. The value of the variable will come from VS; when it runs your Pre-Build Event command, it substitutes project properties for certain macros. The macro you want is probably ProjectDir.
So in the end, you have something like this for your Pre-Build Event's command:
echo 'const char * PROJECT_PATH = "$(ProjectDir)";' > source.cpp
Not sure what language you're using, so adjust accordingly.
To improve the solution slightly, instead of using the Post Build Event Command Line, you can run the command as an MSbuild Exec Task in the BeforeBuild Target of the project.
Related
If I set environment variables for a .Net Core web project in Visual Studio 2017 using the project properties page, I can read the value of the variable using Environment.GetEnvironmentVariable; however, when I set the environment variable for my xUnit testing project and then debug the test, Environment.GetEnvironmentVariable always returns null. Is there something about the fact that it is a testing project that should prevent the variable from being used the same as with the web project? If so, is there a way that I can set the environment variables for a test project? Thank you.
The GetEnvironmentVariable works fine in xUnit tests. The problem is to properly set a variable. If you set the variable at Properties -> Debug page, then the variable is written to Properties\launchSettings.json and Visual Studio makes all work to launch an application with the selected profile. As you could see, launchSettings.json even isn't copied to output folder by default. It's impossible to pass this file as argument to dotnet run or dotnet test, that leads to obvious problem if tests are run automatically on a CI server. So it is not surprising that launchSettings.json isn't considered by a test runner.
Solution: there are a lot of ways to setup a test environment in xUnit:
Constructor
Base class
Fixture
For example, this collection fixture sets up all environment variables from launchSettings.json:
public class LaunchSettingsFixture : IDisposable
{
public LaunchSettingsFixture()
{
using (var file = File.OpenText("Properties\\launchSettings.json"))
{
var reader = new JsonTextReader(file);
var jObject = JObject.Load(reader);
var variables = jObject
.GetValue("profiles")
//select a proper profile here
.SelectMany(profiles => profiles.Children())
.SelectMany(profile => profile.Children<JProperty>())
.Where(prop => prop.Name == "environmentVariables")
.SelectMany(prop => prop.Value.Children<JProperty>())
.ToList();
foreach (var variable in variables)
{
Environment.SetEnvironmentVariable(variable.Name, variable.Value.ToString());
}
}
}
public void Dispose()
{
// ... clean up
}
}
Set Copy to output directory: Always for launchSettings.json to make the file accessible from tests.
A solution for using environment variables in unit tests, for either mstest or xunittest, is through the ".runsettings" file provided for the platform:
UPDATE:
This works only for mstest.
Add a file with .runsettings extension in the project:
Configure environment variables in file "xxx.runsettings" created:
<!-- File name extension must be .runsettings -->
<RunSettings>
<RunConfiguration>
<EnvironmentVariables>
<!-- List of environment variables we want to set-->
<VARIABLE_XXXX>value X</VARIABLE_XXXX>
<VARIABLE_YYYY>value Y</VARIABLE_YYYY>
</EnvironmentVariables>
</RunConfiguration>
</RunSettings>
Add RunSettingsFilePath tag in test .csproj pointing to the .runsettings file.
Important: the path is absolute.
Using $(MSBuildProjectDirectory) variable will return the absolute path to the project diretory.
Another options to use .runsettings are in link below:
https://learn.microsoft.com/pt-br/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019
Great thread helped me find the adapted solution for me.
I needed something that works well for local dev / tests (using VS code) JSON file works fine.
I also needed something that can be used with CI/CD and deployment; environment variables were needed.
My fixture class needs the environment variable to be able to run the tests in the different environments.
I'm using the same principle #Ilya Chumakov except with System.Text.Json (in 2022 using .NET 6...)
I thought that sharing it might help save other people some time:
if (File.Exists(Directory.GetCurrentDirectory()+"/local.settings.json")){
using var file = File.Open(Directory.GetCurrentDirectory()+ "/local.settings.json",FileMode.Open);
var document = JsonDocument.Parse(file);
var variables = document.RootElement.EnumerateObject();
foreach(var variable in variables){
Environment.SetEnvironmentVariable(variable.Name, variable.Value.ToString());
}
}
All the needed variables are at the root of the local.settings.json. adapt if you use it for a lot of things, easy to add an "env" property which contains all your environment variable and just read from it.
For those who use VS code like me. Don't forget to add to your .csproj:
<ItemGroup>
<Content Include="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
Took me also a bit of tinkering to find that out.
I try to make my Qt Installer project more comfortable.
I need to centralize information about my application and components (config.xml and package.xml) in one file. I don't want to jump on different files with same name and search for changeable elements between xml tags.
My first thougt is doing it right in *.pro file of installer project. I place sections of variables in header of installer project file. But where I need to place the code for xml generating?
What is the better (native / comfortable / crossplatform) way to do this?
The answer is simple here: you cannot generate XML files for Qt Installer: you write them manually, as explained in the documentation.
This section describes the following tasks that you must accomplish to create the installer:
Create a package directory that will contain all the configuration files and installable packages.
Create a configuration file that contains information about how to build the installer binaries and online repositories.
Create a package information file that contains information about the installable components.
Create installer content and copy it to the package directory.
Use the binarycreator tool to create the installer.
However, if you look closer at the examples, you can still generate the installer in the *.pro file. Let's pick an example randomly, System Info:
TEMPLATE = aux
INSTALLER = installer
INPUT = $$PWD/config/config.xml $$PWD/packages
example.input = INPUT
example.output = $$INSTALLER
example.commands = ../../bin/binarycreator -c $$PWD/config/config.xml -p $$PWD/packages ${QMAKE_FILE_OUT}
example.CONFIG += target_predeps no_link combine
QMAKE_EXTRA_COMPILERS += example
OTHER_FILES = README
If you want to apply this to your project, I think you'll have to modify the ../../bin/binarycreator line and make it system aware, by changing your PATH. It might be possible to call an external script and parse XML files, and make the substitutions you would like to do, but you'd move the complexity to another place.
Instead of maintaining plain good old XML files, you would be creating something between XSLT and XML. Maybe you could just write XSLT (or XSL or XQUERY) and generate XML but I don't know anyone who is using it anymore. Last time I used it was when I was learning Computer Science a long time ago :)
This is possible using the QMAKE_SUBSTITUTES feature which will substitute qmake variables into the given input files and put the output in the build folder.
This runs at qmake time rather than at build time. If this is suitable then you just need to add a target to copy the generated files from the build dir to your source dir.
If you need it to run at build time then you can create a .pri file containing QMAKE_SUBSTITUTES and a target in the main .pro file that will run qmake on this file during the build process.
Main .pro file:
create_xml.commands += $(QMAKE) $$shell_quote($$PWD/config/generate_xml.pri) $$escape_expand(\n\t)
create_xml.commands += $(COPY) $$shell_quote($${OUT_PWD}/config.xml) $$shell_quote($$PWD/config) $$escape_expand(\n\t)
create_xml.commands += $(COPY) $$shell_quote($${OUT_PWD}/package.xml) $$shell_quote($$PWD/packages/my.app.id/meta) $$escape_expand(\n\t)
create_xml.depends = $$PWD/version.pri
QMAKE_EXTRA_TARGETS += create_xml
generate_xml.pri:
TEMPLATE = aux
message("Generating $$OUT_PWD/config.xml and $$OUT_PWD/package.xml")
# Get the version number
include(version.pri)
APP_VERSION = $$VERSION
QMAKE_SUBSTITUTES += package.xml.in config.xml.in
config.xml.in: Note that you need to escape the quotes.
<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<Installer>
<Name>MyApp</Name>
<Version>$$APP_VERSION</Version>
...
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.
I am actually evaluate sonar (sonarsource.org) for using it with c#.
Is it possible to specify a different binaries folder (MsBuild OutDir Property) for csharp projects? I use a custom OutDir on our build server to have the binaries/Buildoutput of every csharp project in one place.
Tried (with java runner and sonar-project.properties)
binaries=Binaries
And
sonar.gendarme.assemblies=Binaries/*.*
sonar.fxcop.assemblies=Binaries/*.*
BTW: how to specify search paths for gallio code coverage? My test assemblies are also not in bin/Debug.
Any Ideas?
Found out that wild cards aren't possible. But: should the path to the assembly be relative or absolute? Relative...
File basedir = (vsProject == null) ? solution.getSolutionDir() : vsProject.getDirectory();
...
File file = new File(basedir, filePath);
But still no success with
sonar.fxcop.assemblies=../Binaries/Assembly1.dll;../Binaries/Assembly2.dll
I have code which generates resources which I want to save in a subdirectory of my $(PROJECT_DIR).
How do I get the real path from this environment variable in code?
open the projects build settings and add SAVEPATH=#\"$(PROJECT_DIR)\" to the preprocessor macros.
Then you can get the project directory like this:
NSString *projectDir = SAVEPATH;
I'm not sure if Xcode 3.2.6 has changed the way that () are used with environment variables, but I've found that using the following pre-processor macro works for me (#fluchtpunkt's answer gives me a compiler error):
PROJECT_DIR=#\""$PROJECT_DIR"\"
Then I can do:
NSString *savePath = [PROJECT_DIR stringByAppendingPathComponent:#"Save Folder"];