If I create a List list.. Visual Studio offers its members with intellisense, but there is no documentation for the members. If I go to the definition of List, I see the following:
[DefaultMember("Item")]
public class List<T> : IEnumerable, ICollection, IList, ICollection<T>, IEnumerable<T>, IList<T>
{
// ...
public void Add(T item);
public void Clear();
public bool Contains(T item);
// ...
}
There is no comments/descriptions for any of the members. This applies to any other core classes.
What can I do to make Visual Studio 2017 show the documentation so I don't have to Alt+Tab to the official C# reference documentation website any time I want to know what a method does?
Is there any SDK library I have to add in order to have documentation?
I'm using Visual Studio on Unity projects.
You can do this but you have to know two things
1.Where Unity's framework dll are located:
When "Scripting Runtime Version" is set to ".NET 3.5 Equivalent" in the Editor, the C# DLL API used is at:
<UnityInstallationDirecory>\Editor\Data\MonoBleedingEdge\lib\mono\unity
When "Scripting Runtime Version" is set to ".NET 4.x Equivalent" in the Editor, the latest framework is used the path ends with the framework version:
<UnityInstallationDirecory>\Editor\Data\MonoBleedingEdge\lib\mono\<API-version>
This path may change in the future. To find the current path to the dll Unity is using, simply expand the Assembly and References in the "Solution Explorer" tab in Visual Studio then select one of the C# DLL. In the example below, System.dll is selected, the path will be displayed under the property.
2.Where the C# standard framework dll are located:
When using ".NET 3.5 Equivalent" in the Unity Editor, the corresponding C# framework API used is at:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client
When using ".NET 4.x Equivalent" in the Unity Editor, the corresponding C# framework API used is at:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\<API-version>
Showing C# core documentation in Visual Studio:
Now that you know the locations, notice that each dll in the standard framework location from #2 has a complimentary xml file that ends with .xml extension. For example, the System.Core.dll dll, has complementary file named System.Core.xml in the-same folder. Each xml file contains the documentation for each corresponding dll file.
All you have to do is copy xml file for each dll file from the standard framework location into Unity's framework dll location. Restart Visual Studio and documentation should be working.
This is time consuming to do manually so I made an Editor plugin to handle it. Enable it by going to the Programmer-->Enable Core Documentation menu and disable it by going to the Programmer-->Disable Core Documentation menu. You must restart Visual Studio in order for this to take effect.
using System;
using System.IO;
using System.Linq;
using UnityEditor;
using UnityEngine;
public class DocEnabler : MonoBehaviour
{
//Replace both with the proper paths on your system
static string unityFrameworkPath = #"G:\Applications\Unity\Editor\Data\MonoBleedingEdge\lib\mono\unity";
static string stdCoreFrameworkPath = #"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client";
[MenuItem("Programmer/Enable Core Documentation")]
static void EnableCoreDoc()
{
CopyFilesByExt(stdCoreFrameworkPath, unityFrameworkPath, "xml");
}
[MenuItem("Programmer/Disable Core Documentation")]
static void DisableCoreDoc()
{
DeleteFilesByExt(unityFrameworkPath, "xml");
}
static void DeleteFilesByExt(string path, string ext)
{
DirectoryInfo drctyInfo = new DirectoryInfo(path);
FileInfo[] files = drctyInfo.GetFiles("*." + ext)
.Where(p => p.Extension == "." + ext).ToArray();
foreach (FileInfo file in files)
{
try
{
file.Attributes = FileAttributes.Normal;
file.Delete();
//File.Delete(file.FullName);
}
catch (Exception e)
{
Debug.Log("Error while deleting file: " + file.Name + "\r\n" + e.Message);
}
}
DoneMessage();
}
static void CopyFilesByExt(string source, string destPath, string ext)
{
DirectoryInfo drctyInfo = new DirectoryInfo(source);
FileInfo[] files = drctyInfo.GetFiles("*." + ext)
.Where(p => p.Extension == "." + ext).ToArray();
foreach (FileInfo file in files)
{
try
{
string fromPath = file.FullName;
string toPath = Path.Combine(destPath, file.Name);
file.CopyTo(toPath, true);
//File.Copy(fromPath, toPath, true);
}
catch (Exception e)
{
Debug.Log("Error while Copying file: " + file.Name + "\r\n" + e.Message);
}
}
DoneMessage();
}
static void DoneMessage()
{
Debug.Log("Action complete. Restart Visual Studio for the changes to take effect");
}
}
Coming to this in 2021. Programmer's solution still works, but the locations have changed and there is another copy that needs to happen to support netstandard 2.0.
I hope Programmer doesn't mind but I adjusted the script with the changed default locations and added the netstandard 2.0 locations. JetBrains Rider has the same problem and solution.
My experience in this field is 2 days strong, so use with caution. But it solved all of my problems.
EDIT: I discovered that not only can these dir names vary among systems, but Windows doesn't ship with the netstandard reference by default. I'll correct this post when I find where it came from.
using System;
using System.IO;
using System.Linq;
using UnityEditor;
using UnityEngine;
public class DocEnabler : MonoBehaviour
{
//Replace both with the proper paths on your system
// .NET 4.x
static string unityFrameworkPath = #"C:\Program Files\Unity\Hub\Editor\2021.1.5f1\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api";
static string microsoftFrameworkPath = #"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.X";
// .NETSTANDARD 2.0
static string unityNetStandardPath = #"C:\Program Files\Unity\Hub\Editor\2021.1.5f1\Editor\Data\NetStandard\ref\2.0.0";
static string microsoftNetStandardPath = #"C:\Program Files\dotnet\packs\NETStandard.Library.Ref\2.1.0\ref\netstandard2.1";
[MenuItem("Programmer/Enable Core Documentation")]
static void EnableCoreDoc()
{
CopyFilesByExt(microsoftFrameworkPath, unityFrameworkPath, "xml");
CopyFilesByExt(microsoftNetStandardPath, unityNetStandardPath, "xml");
}
[MenuItem("Programmer/Disable Core Documentation")]
static void DisableCoreDoc()
{
DeleteFilesByExt(unityFrameworkPath, "xml");
DeleteFilesByExt(unityNetStandardPath, "xml");
}
static void DeleteFilesByExt(string path, string ext)
{
DirectoryInfo dirInfo = new DirectoryInfo(path);
FileInfo[] files = dirInfo.GetFiles("*." + ext)
.Where(p => p.Extension == "." + ext).ToArray();
foreach (FileInfo file in files)
{
try
{
file.Attributes = FileAttributes.Normal;
file.Delete();
}
catch (Exception e)
{
Debug.Log("Error while deleting file: " + file.Name + "\r\n" + e.Message);
}
}
DoneMessage();
}
static void CopyFilesByExt(string source, string destPath, string ext)
{
DirectoryInfo dirInfo = new DirectoryInfo(source);
FileInfo[] files = dirInfo.GetFiles("*." + ext)
.Where(p => p.Extension == "." + ext).ToArray();
foreach (FileInfo file in files)
{
try
{
string toPath = Path.Combine(destPath, file.Name);
file.CopyTo(toPath, true);
}
catch (Exception e)
{
Debug.Log("Error while Copying file: " + file.Name + "\r\n" + e.Message);
}
}
DoneMessage();
}
static void DoneMessage()
{
Debug.Log("Action complete. Restart Visual Studio for the changes to take effect");
}
}
I would've posted as a comment and included some proof images, but I don't have enough karma yet.
Here's a link to an image of it working on a .NET 2.0 project in Visual Studio.
I found an answer in the Unity Answers site Here.
Answer by Blue_Ninja0 ยท Sep 21, 2017 at 09:41 PM
It has been brought to my attention that Unity doesn't include the System.xml file required for Intellisense documentation for their old mono runtime.
It seems from Unity 2017 onwards, as long as you enable .NET 4.6 on the API Compatibility Level setting on the Player Settings, you will get full documentation. I have tested and it worked fine.
Related
We would like to distribute our project with assembly files instead of .cs scripts.
We thought that this would be easy thanks to assembly definition files, as unity is creating assembly files for the scripts they refer to anyway.
It turns out that when removing the .cs files and putting the assemblies, we ran into a problem :
The monobehaviors defined in the assemblies (so previously in our scripts) can't be added manually to a scene :
"Can't add script component xxx because the script class cannot be found"
While if we add the component through script (i.e. AddComponent) it works.
I'm using Unity 2017.3.f1 to generate the assembly files
Is there a trick to make this work ? or should I try to generate the assemblies using another approach ?
OP here.
Short answer is : don't keep both asmdef and assembly files. Remove the asmdef file if you replace the scripts with the generated assembly
What I ended up doing is the roughly following (this was for CI purpose):
First, we need to make sure Unity compiles the assembly file. So I have a GenerateAssemblies.cs file in an Editor folder that can be executed from command line:
GenerateAssemblies.cs:
using System;
using System.Collections.Generic;
using System.Linq;
using UnityEditor;
using UnityEditor.Compilation;
using UnityEngine;
[InitializeOnLoad]
public static class GenerateAssemblies
{
private static string BATCH_MODE_PARAM = "-batchmode";
private const string REPLACE_ASSEMBLY_PARAM = "-replaceassembly";
static GenerateAssemblies()
{
List<String> args = Environment.GetCommandLineArgs().ToList();
if (args.Any(arg => arg.ToLower().Equals(BATCH_MODE_PARAM)))
{
Debug.LogFormat("GenerateAssemblies will try to parse the command line to replace assemblies.\n" +
"\t Use {0} \"assemblyname\" for every assembly you wish to replace"
, REPLACE_ASSEMBLY_PARAM);
}
if (args.Any(arg => arg.ToLower().Equals(REPLACE_ASSEMBLY_PARAM))) // is a replacement requested ?
{
int lastIndex = 0;
while (lastIndex != -1)
{
lastIndex = args.FindIndex(lastIndex, arg => arg.ToLower().Equals(REPLACE_ASSEMBLY_PARAM));
if (lastIndex >= 0 && lastIndex + 1 < args.Count)
{
string assemblyToReplace = args[lastIndex + 1];
if (!assemblyToReplace.EndsWith(ReplaceAssemblies.ASSEMBLY_EXTENSION))
assemblyToReplace = assemblyToReplace + ReplaceAssemblies.ASSEMBLY_EXTENSION;
ReplaceAssemblies.instance.AddAssemblyFileToReplace(assemblyToReplace);
Debug.LogFormat("Added assembly {0} to the list of assemblies to replace.", assemblyToReplace);
lastIndex++;
}
}
CompilationPipeline.assemblyCompilationFinished += ReplaceAssemblies.instance.ReplaceAssembly; /* This serves as callback after Unity as compiled an assembly */
Debug.Log("Forcing recompilation of all scripts");
// to force recompilation
PlayerSettings.SetScriptingDefineSymbolsForGroup(BuildTargetGroup.Standalone, PlayerSettings.GetScriptingDefineSymbolsForGroup(BuildTargetGroup.Standalone) + ";DUMMY_SYMBOL");
AssetDatabase.Refresh(ImportAssetOptions.ForceUpdate);
}
}
}
Then I have a ReplaceAssemblies.cs file in an editor folder that will :
find the assembly file correpsonding to the asmdef file
save the guid/classes correspondance of the script files
move the script files in a temporary folder
move the assembly in the same folder as the asmdef file
move the asmdef to a temporary folder
Replace the Guid and File ID values for each script in the assembly (to avoid breaking references in scenes and prefabs)
ReplaceAssemblies.cs
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using UnityEditor;
using UnityEditor.Compilation;
using UnityEngine;
public class ReplaceAssemblies : ScriptableSingleton<ReplaceAssemblies>
{
public static string ASSEMBLY_EXTENSION = ".dll";
public static string ASSEMBLY_DEFINITION_EXTENSION = ".asmdef";
[SerializeField]
private List<String> assembliesFilesToReplace = new List<string>();
[SerializeField]
private List<string> pathsOfAssemblyFilesInAssetFolder = new List<string>();
[SerializeField]
private List<string> pathsOfAssemblyFilesCreatedByUnity = new List<string>();
[SerializeField]
private string tempSourceFilePath;
private static readonly string[] fileListPath = { "*.prefab", "*.unity", "*.asset" };
public string TempSourceFilePath
{
get
{
if (String.IsNullOrEmpty(tempSourceFilePath))
{
tempSourceFilePath = FileUtil.GetUniqueTempPathInProject();
}
return tempSourceFilePath;
}
}
void OnEnable()
{
Debug.Log("temp dir : " + TempSourceFilePath);
}
public void ReplaceAssembly(string assemblyPath, CompilerMessage[] messages)
{
string assemblyFileName = assembliesFilesToReplace.Find(assembly => assemblyPath.EndsWith(assembly));
// is this one of the assemblies we want to replace ?
if (!String.IsNullOrEmpty(assemblyFileName))
{
string[] assemblyDefinitionFilePaths = Directory.GetFiles(".", Path.GetFileNameWithoutExtension(assemblyFileName) + ASSEMBLY_DEFINITION_EXTENSION, SearchOption.AllDirectories);
if (assemblyDefinitionFilePaths.Length > 0)
{
string assemblyDefinitionFilePath = assemblyDefinitionFilePaths[0];
ReplaceAssembly(assemblyDefinitionFilePath);
}
}
}
public void AddAssemblyFileToReplace(string assemblyFile)
{
assembliesFilesToReplace.Add(assemblyFile);
}
private void ReplaceAssembly(string assemblyDefinitionFilePath)
{
Debug.LogFormat("Replacing scripts for assembly definition file {0}", assemblyDefinitionFilePath);
string asmdefDirectory = Path.GetDirectoryName(assemblyDefinitionFilePath);
string assemblyName = Path.GetFileNameWithoutExtension(assemblyDefinitionFilePath);
Assembly assemblyToReplace = CompilationPipeline.GetAssemblies().ToList().Find(assembly => assembly.name.ToLower().Equals(assemblyName.ToLower()));
string assemblyPath = assemblyToReplace.outputPath;
string assemblyFileName = Path.GetFileName(assemblyPath);
string[] assemblyFilePathInAssets = Directory.GetFiles("./Assets", assemblyFileName, SearchOption.AllDirectories);
// save the guid/classname correspondance of the scripts that we will remove
Dictionary<string, string> oldGUIDToClassNameMap = new Dictionary<string, string>();
if (assemblyFilePathInAssets.Length <= 0)
{
// Move all script files outside the asset folder
foreach (string sourceFile in assemblyToReplace.sourceFiles)
{
string tempScriptPath = Path.Combine(TempSourceFilePath, sourceFile);
Directory.CreateDirectory(Path.GetDirectoryName(tempScriptPath));
if (!File.Exists(sourceFile))
Debug.LogErrorFormat("File {0} does not exist while the assembly {1} references it.", sourceFile, assemblyToReplace.name);
Debug.Log("will move " + sourceFile + " to " + tempScriptPath);
// save the guid of the file because we may need to replace it later
MonoScript monoScript = AssetDatabase.LoadAssetAtPath<MonoScript>(sourceFile);
if (monoScript != null && monoScript.GetClass() != null)
oldGUIDToClassNameMap.Add(AssetDatabase.AssetPathToGUID(sourceFile), monoScript.GetClass().FullName);
FileUtil.MoveFileOrDirectory(sourceFile, tempScriptPath);
}
Debug.Log("Map of GUID/Class : \n" + String.Join("\n", oldGUIDToClassNameMap.Select(pair => pair.Key + " : " + pair.Value).ToArray()));
string finalAssemblyPath = Path.Combine(asmdefDirectory, assemblyFileName);
Debug.Log("will move " + assemblyPath + " to " + finalAssemblyPath);
FileUtil.MoveFileOrDirectory(assemblyPath, finalAssemblyPath);
string tempAsmdefPath = Path.Combine(TempSourceFilePath, Path.GetFileName(assemblyDefinitionFilePath));
Debug.Log("will move " + assemblyDefinitionFilePath + " to " + tempAsmdefPath);
FileUtil.MoveFileOrDirectory(assemblyDefinitionFilePath, tempAsmdefPath);
// Rename the asmdef meta file to the dll meta file so that the dll guid stays the same
FileUtil.MoveFileOrDirectory(assemblyDefinitionFilePath + ".meta", finalAssemblyPath + ".meta");
pathsOfAssemblyFilesInAssetFolder.Add(finalAssemblyPath);
pathsOfAssemblyFilesCreatedByUnity.Add(assemblyPath);
// We need to refresh before accessing the assets in the new assembly
AssetDatabase.Refresh();
// We need to remove .\ when using LoadAsslAssetsAtPath
string cleanFinalAssemblyPath = finalAssemblyPath.Replace(".\\", "");
var assetsInAssembly = AssetDatabase.LoadAllAssetsAtPath(cleanFinalAssemblyPath);
// list all components in the assembly file.
var assemblyObjects = assetsInAssembly.OfType<MonoScript>().ToArray();
// save the new GUID and file ID for the MonoScript in the new assembly
Dictionary<string, KeyValuePair<string, long>> newMonoScriptToIDsMap = new Dictionary<string, KeyValuePair<string, long>>();
// for each component, replace the guid and fileID file
for (var i = 0; i < assemblyObjects.Length; i++)
{
long dllFileId;
string dllGuid = null;
if (AssetDatabase.TryGetGUIDAndLocalFileIdentifier(assemblyObjects[i], out dllGuid, out dllFileId))
{
string fullClassName = assemblyObjects[i].GetClass().FullName;
newMonoScriptToIDsMap.Add(fullClassName, new KeyValuePair<string, long>(dllGuid, dllFileId));
}
}
Debug.Log("Map of Class/GUID:FILEID : \n" + String.Join("\n", newMonoScriptToIDsMap.Select(pair => pair.Key + " : " + pair.Value.Key + " - " + pair.Value.Value).ToArray()));
ReplaceIdsInAssets(oldGUIDToClassNameMap, newMonoScriptToIDsMap);
}
else
{
Debug.Log("Already found an assembly file named " + assemblyFileName + " in asset folder");
}
}
/// <summary>
/// Replace ids in all asset files using the given maps
/// </summary>
/// <param name="oldGUIDToClassNameMap">Maps GUID to be replaced => FullClassName</param>
/// <param name="newMonoScriptToIDsMap">Maps FullClassName => new GUID, new FileID</param>
private static void ReplaceIdsInAssets(Dictionary<string, string> oldGUIDToClassNameMap, Dictionary<string, KeyValuePair<string, long>> newMonoScriptToIDsMap)
{
StringBuilder output = new StringBuilder("Report of replaced ids : \n");
// list all the potential files that might need guid and fileID update
List<string> fileList = new List<string>();
foreach (string extension in fileListPath)
{
fileList.AddRange(Directory.GetFiles(Application.dataPath, extension, SearchOption.AllDirectories));
}
foreach (string file in fileList)
{
string[] fileLines = File.ReadAllLines(file);
for (int line = 0; line < fileLines.Length; line++)
{
//find all instances of the string "guid: " and grab the next 32 characters as the old GUID
if (fileLines[line].Contains("guid: "))
{
int index = fileLines[line].IndexOf("guid: ") + 6;
string oldGUID = fileLines[line].Substring(index, 32); // GUID has 32 characters.
if (oldGUIDToClassNameMap.ContainsKey(oldGUID) && newMonoScriptToIDsMap.ContainsKey(oldGUIDToClassNameMap[oldGUID]))
{
fileLines[line] = fileLines[line].Replace(oldGUID, newMonoScriptToIDsMap[oldGUIDToClassNameMap[oldGUID]].Key);
output.AppendFormat("File {0} : Found GUID {1} of class {2}. Replaced with new GUID {3}.", file, oldGUID, oldGUIDToClassNameMap[oldGUID], newMonoScriptToIDsMap[oldGUIDToClassNameMap[oldGUID]].Key);
if (fileLines[line].Contains("fileID: "))
{
index = fileLines[line].IndexOf("fileID: ") + 8;
int index2 = fileLines[line].IndexOf(",", index);
string oldFileID = fileLines[line].Substring(index, index2 - index); // GUID has 32 characters.
fileLines[line] = fileLines[line].Replace(oldFileID, newMonoScriptToIDsMap[oldGUIDToClassNameMap[oldGUID]].Value.ToString());
output.AppendFormat("Replaced fileID {0} with {1}", oldGUID, newMonoScriptToIDsMap[oldGUIDToClassNameMap[oldGUID]].Value.ToString());
}
output.Append("\n");
}
}
}
//Write the lines back to the file
File.WriteAllLines(file, fileLines);
}
Debug.Log(output.ToString());
}
[MenuItem("Tools/Replace Assembly")]
public static void ReplaceAssemblyMenu()
{
string assemblyDefinitionFilePath = EditorUtility.OpenFilePanel(
title: "Select Assembly Definition File",
directory: Application.dataPath,
extension: ASSEMBLY_DEFINITION_EXTENSION.Substring(1));
if (assemblyDefinitionFilePath.Length == 0)
return;
instance.ReplaceAssembly(assemblyDefinitionFilePath);
}
}
I was experiencing this issue, and like you, I was using the information provided from asmdef files to provide all the required information (which .cs files, what references, defines, etc) to build an assembly.
I found that the issue was the DLL I was creating had the same name as the asmdef file I was using to provide the information. Even though the asmdef file was no longer being compiled (because all the scripts had been removed to build the DLL), it was still interfering with the project.
So for me, the inconsistency between accessing a script from inside the editor and from inside scripts was because there was a DLL and as asmdef file with the same name in the project.
Giving the compiled DLL a different name or removing the asmdef file was the solution for me.
Just tested with Unity 2019.3.0b1.
Content of test class:
using System.Reflection;
using UnityEngine;
namespace Assets.Test
{
public class TestBehaviour : MonoBehaviour
{
void Start()
{
Debug.Log(Assembly.GetAssembly(GetType()));
}
}
}
First project with source code and assembly definition file
Second project with the generated DLL, working as expected
As far as i'm concerned, the use of asmdef merely forces unity3d to compile your scripts into separate assemblies that are then referenced by your project.
Actually, it creates projects in your unity solution that contain your .cs files and each of these projects is compiled into its own output assembly.
The error you are seeing might be related to assembly caching.
I've had that error a few months ago and it was due to an outdated assembly still being cached.
As a result, unity3d editor kinda hiccuped when loading the project and therefore could not load the specific assembly.
I fixed it by deleting the directories Library, obj and Temp and then reloaded the unity3d project.
To get rid of that for good, we have moved away from asmdef and .cs files inside our unity projects once and for all.
All our scripts have been extracted to separate projects that are never touched by unity3d.
Every project references UnityEngine.dll and/or UnityEditor.dll (for Editor assemblies) depending on which unity3d types it may require.
The projects are built locally using Visual Studio or server side in our CI pipeline.
Output is copied manually into the assets directory of a unity project where it is then loaded from within unity3d editor.
This last step is a pain admittedly but i have yet to find time to streamline this process some more.
This approach has a few benefits
We are in control of our code in one single repository.
There is only one single point of truth and every developer commits changes onto the same code base.
There are no copies of .cs files across any number of unity projects that consume our types.
There is no need to figure out merge conflicts from updating a unitypackage where there have been deletions.
Unit tests can be done server side (CI pipeline) without the need of some docker image with unity3d on top (ofc there are restrictions on how much you can test without the entire unity3d environment running).
We create our own NuGet packages that can be referenced in projects (vcproj, not unity projects!).
Types deriving from MonoBehaviour can be added to GameObjects via code or via unity3d editor.
You also get to explore loaded assemblies inside your unity3d editor project view by clicking on the arrow of an assembly which will expand to show the list of contained relevant types.
Let's talk about downsides
One example is that we use SteamVR for interacting with controls.
The SteamVR plugin for unity3d is released through unity's asset store and annoyingly it contains script files and resources but no assemblies.
This goes for pretty much all assets in the store by the way.
Since we can't build against code, we have to go through the trouble of compiling SteamVR once and then copy the output assembly somewhere else.
This is not just as tedious as a task can be, it also has some limitations of its own which i get to later.
Anyway, this lets us reference a compiled asset with our own code so we get to use asset specific types like SteamVR_Action in our code without having to use unity3d editor and script files in unity projects (or reflection which would be even worse).
Limitations of compiled assets like this are two fold.
For once, it is horribly inefficient to get there in the first place.
On the other hand, you'll only have to do that once for every version of an asset.
Once that's done, make it a private NuGet package and you're golden.
The other limitation is the way how unity3d approaches dependency injection.
Actually i'm not entirely sure what it really is they try to do but here goes.
Unity3d wants you to only ever reference assemblies from within ../UnityInstallDirectory/Editor/Data/Managed/.
In a perfect world, your own assemblies reference that big gunky UnityEngine.dll in this directory and once loaded by unity3d editor everything works as expected.
When you compile a unity project from within unity3d editor however, the resulting assembly references all the assemblies from within ../UnityInstallDirectory/Editor/Data/Managed/UnityEngine/ which contains a very small version of UnityEngine.dll which in turn acts as a type forwarder to all the other sub modules.
Not such a perfect world now is it?
Your previously compiled asset requires the type MonoBehaviour to sit in an assembly called UnityEngine.CoreModule.dll.
Your own project however expects it to sit in UnityEngine.dll since you're a good fellow and follow the rules.
This is just asking for trouble and to get around this problem we are now directly referencing all the managed sub modules from within ../UnityInstallDirectory/Editor/Data/Managed/UnityEngine/.
We also ignore unity3d editor moaning about how we are doing it wrong.
tl;dr
By doing all from above and leaving asmdef and .cs files out of the equation we are able to build, unit test and pack our logic and types into assemblies.
We are also able to keep a clean code base that can be easily maintained and extended without dozens of copies of the same code in multiple locations and/or repositories.
Why unity3d does things the way they do, i'll never understand.
I do know there is a thing called Building from HEAD but since the entirety of the .net ecosystem is using the binary format to share content in the form of referable assemblies, why would you want to do things differently?
This is a topic for another day though.
If you made it all the way through this post, i sincerely hope it is helping you fix your problem at hand.
In case i misinterpreted your question ... sorry :-)
Unity3d is weird ...
I have a web project like:
namespace Web
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
lbResult.Text = PathTest.GetBasePath();
}
}
}
The method PathTest.GetBasePath() is defined in another Project like:
namespace TestProject
{
public class PathTest
{
public static string GetBasePath()
{
return AppDomain.CurrentDomain.BaseDirectory;
}
}
}
Why it's display ...\Web\ while the TestProject assembly is compiled into bin folder(in other words it should display ...\Web\bin in my thought).
Now I got a troublesome if I modified method into:
namespace TestProject
{
public class FileReader
{
private const string m_filePath = #"\File.config";
public static string Read()
{
FileStream fs = null;
fs = new FileStream(AppDomain.CurrentDomain.BaseDirectory + m_filePath,FileMode.Open, FileAccess.Read);
StreamReader reader = new StreamReader(fs);
return reader.ReadToEnd();
}
}
}
The File.config is created in TestProject. Now AppDomain.CurrentDomain.BaseDirectory + m_filePath will returen ..\Web\File.config (actually the file was be copied into ..\Web\bin\File.config), an exception will be thrown.
You could say that I should modified m_filePath to #"\bin\File.config". However If I use this method in a Console app in your suggest, AppDomain.CurrentDomain.BaseDirectory + m_filePath will return ..\Console\bin\Debug\bin\File.config (actually the file was copyed into .\Console\bin\Debug\File.config), an exception will be thrown due to surplus bin.
In other words, in web app, AppDomain.CurrentDomain.BaseDirectory is a different path where file be copyed into (lack of /bin), but in console app it's the same one path.
Any one can help me?
Per MSDN, an App Domain "Represents an application domain, which is an isolated environment where applications execute." When you think about an ASP.Net application the root where the app resides is not the bin folder. It is totally possible, and in some cases reasonable, to have no files in your bin folder, and possibly no bin folder at all. Since AppDomain.CurrentDomain refers to the same object regardless of whether you call the code from code behind or from a dll in the bin folder you will end up with the root path to the web site.
When I've written code designed to run under both asp.net and windows apps usually I create a property that looks something like this:
public static string GetBasePath()
{
if(System.Web.HttpContext.Current == null) return AppDomain.CurrentDomain.BaseDirectory;
else return Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"bin");
}
Another (untested) option would be to use:
public static string GetBasePath()
{
return System.Reflection.Assembly.GetExecutingAssembly().Location;
}
In case you want a solution that works for WinForms and Web Apps:
public string ApplicationPath
{
get
{
if (String.IsNullOrEmpty(AppDomain.CurrentDomain.RelativeSearchPath))
{
//exe folder for WinForms, Consoles, Windows Services
return AppDomain.CurrentDomain.BaseDirectory;
}
else
{
//bin folder for Web Apps
return AppDomain.CurrentDomain.RelativeSearchPath;
}
}
}
The above code snippet is for binaries locations.
The AppDomain.CurrentDomain.BaseDirectory is still a valid path for Web Apps, it's just the root folder where the web.config and Global.asax are, and is same as Server.MapPath(#"~\");
If you use AppDomain.CurrentDomain.SetupInformation.PrivateBinPath instead of BaseDirectory, then you should get the correct path.
When ASP.net builds your site it outputs build assemblies in its special place for them. So getting path in that way is strange.
For asp.net hosted applications you can use:
string path = HttpContext.Current.Server.MapPath("~/App_Data/somedata.xml");
Is there a way to programmatically get the FileInfo/Path of the ildasm.exe/ilasm.exe executables? I'm attempting to decompile and recompile a dll/exe file appropriately after making some alterations to it (I'm guessing PostSharp does something similar to alter the IL after the compilation).
I found a blog post that pointed to:
var pfDir = Environment.GetFolderPath(Environment.SpecialFolders.ProgramFiles));
var sdkDir = Path.Combine(pfDir, #"Microsoft SDKs\Windows\v6.0A\bin");
...
However, when I ran this code the directory did not exist (mainly because my SDK version is 7.1), so on my local machine the correct path is #"Microsoft SDKs\Windows\v7.1\bin". How do I ensure I can actually find the ildasm.exe?
Similarly, I found another blog post on how to get access to ilasm.exe as:
string windows = Environment.GetFolderPath(Environment.SpecialFolder.System);
string fwork = Path.Combine(windows, #"..\Microsoft.NET\Framework\v2.0.50727");
...
While this works, I noticed that I have Framework and Framework64, and within Framework itself I have all of the versions up to v4.0.30319 (same with Framework64). So, how do I know which one to use? Should it be based on the .NET Framework version I'm targetting?
Summary:
How do I appropriately guarantee to find the correct path to ildasm.exe?
How do I appropriately select the correct ilasm.exe to compile?
One option would be to reference Microsoft.Build.Utilities.Core and use:
var ildasm = Microsoft.Build.Utilities.ToolLocationHelper.GetPathToDotNetFrameworkSdkFile("ildasm.exe", TargetDotNetFrameworkVersion.VersionLatest);
var ilasm = Microsoft.Build.Utilities.ToolLocationHelper.GetPathToDotNetFrameworkFile("ilasm.exe", TargetDotNetFrameworkVersion.VersionLatest);
Right now on my machine this returns:
ildasm = C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\ildasm.exe
ilasm = C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe
I recently needed to do this so I trawled the interwebs for all the possible paths of the Windows SDK and search through those in most recent known order. I also check for whether the OS and process is 64bit and then just use that version by looking in the appropriate Program Files folders. I don't think choosing 64-bit over the 32-bit versions of the tools has any great significance. The x86 version of ILAsm can happily assemble 64-bit preferred assemblies without a hitch, it's all IL and not actually executing any of the code.
ILDasm is part of the Windows SDK where ILAsm is just the .NET Framework SDK so here are some static methods to hunt them down with. The code is baked for .NET 4.0 but you could make some minor tweaks to get it building on .NET 2.0 if you want.
// ILDasm.exe will be somewhere in here
private static string FindPathForWindowsSdk()
{
string[] windowsSdkPaths = new[]
{
#"Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\",
#"Microsoft SDKs\Windows\v8.0A\bin\",
#"Microsoft SDKs\Windows\v8.0\bin\NETFX 4.0 Tools\",
#"Microsoft SDKs\Windows\v8.0\bin\",
#"Microsoft SDKs\Windows\v7.1A\bin\NETFX 4.0 Tools\",
#"Microsoft SDKs\Windows\v7.1A\bin\",
#"Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\",
#"Microsoft SDKs\Windows\v7.0A\bin\",
#"Microsoft SDKs\Windows\v6.1A\bin\",
#"Microsoft SDKs\Windows\v6.0A\bin\",
#"Microsoft SDKs\Windows\v6.0\bin\",
#"Microsoft.NET\FrameworkSDK\bin"
};
foreach (var possiblePath in windowsSdkPaths)
{
string fullPath = string.Empty;
// Check alternate program file paths as well as 64-bit versions.
if (Environment.Is64BitProcess)
{
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), possiblePath, "x64");
if (Directory.Exists(fullPath))
{
return fullPath;
}
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86), possiblePath, "x64");
if (Directory.Exists(fullPath))
{
return fullPath;
}
}
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), possiblePath);
if (Directory.Exists(fullPath))
{
return fullPath;
}
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86), possiblePath);
if (Directory.Exists(fullPath))
{
return fullPath;
}
}
return null;
}
// ILAsm.exe will be somewhere in here
private static string FindPathForDotNetFramework()
{
string[] frameworkPaths = new[]
{
#"Microsoft.NET\Framework\v4.0.30319",
#"Microsoft.NET\Framework\v2.0.50727"
};
foreach (var possiblePath in frameworkPaths)
{
string fullPath = string.Empty;
if (Environment.Is64BitProcess)
{
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), possiblePath.Replace(#"\Framework\", #"\Framework64\"));
if (Directory.Exists(fullPath))
{
return fullPath;
}
}
fullPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Windows), possiblePath);
if (Directory.Exists(fullPath))
{
return fullPath;
}
}
return null;
}
You can augment this by passing in the executable you are looking for and change Directory.Exists with File.Exists as well, up to you. You could also take the possible lists and put them in a config file so you can add more without recompiling.
I'm just starting with a new product and I guess I don't understand the PATH variable. My documentation says to update the PATH like this which I do successfully in a little console application:
using HP.HPTRIM.SDK;
namespace TestSDKforTRIM71
{
class Program
{
static void Main(string[] args)
{
string trimInstallDir = #"C:\Program Files\Hewlett-Packard\HP TRIM";
string temp = Environment.GetEnvironmentVariable("PATH") + ";" + trimInstallDir;
Environment.SetEnvironmentVariable("PATH", temp);
DoTrimStuff();
}
public static void DoTrimStuff()
{
using (Database db = new Database())
{
db.Connect();
Console.WriteLine(db.Id);
}
Console.ReadKey();
}
}
}
In the above project, I have a reference to HP.HPTRIM.SDK which exists at:
C:\Program Files\Hewlett-Packard\HP TRIM\HP.HPTRIM.SDK.dll
After the above ran successfully, I tried to permanently change the PATH by using Control Panel:System:Advanced:Environment Variables. I verified the above PATH by examining the registry at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. I see the following as the last entry in the PATH value:
;C:\Program Files\Hewlett-Packard\HP TRIM\
I thought this would permanently SET this at the end of the PATH but when I run the above console program with a few lines commented out I get the FileNotFoundException (see below). I am confused about how to get this in the PATH and not have to worry about it anymore.
using HP.HPTRIM.SDK;
namespace TestSDKforTRIM71
{
class Program
{
static void Main(string[] args)
{
//string trimInstallDir = #"C:\Program Files\Hewlett-Packard\HP TRIM";
//string temp = Environment.GetEnvironmentVariable("PATH") + ";" + trimInstallDir;
//Environment.SetEnvironmentVariable("PATH", temp);
DoTrimStuff(); // without setting the PATH this fails despite being in REGISTRY...
}
public static void DoTrimStuff()
{
using (Database db = new Database())
{
db.Connect();
Console.WriteLine(db.Id);
}
Console.ReadKey();
}
}
}
Only newly started processes that don't inherit their environment from their parent will have the updated PATH. You'll have to at least restart the Visual Studio hosting process, close and re-open your solution. To cover all possible corners, log out and log back in so that Windows Explorer (and thus Visual Studio) also start using the updated environment.
Instead of running an external program with its path hardcoded, I would like to get the current Project Dir. I'm calling an external program using a process in the custom task.
How would I do that? AppDomain.CurrentDomain.BaseDirectory just gives me the location of VS 2008.
using System;
using System.IO;
// This will get the current WORKING directory (i.e. \bin\Debug)
string workingDirectory = Environment.CurrentDirectory;
// or: Directory.GetCurrentDirectory() gives the same result
// This will get the current PROJECT bin directory (ie ../bin/)
string projectDirectory = Directory.GetParent(workingDirectory).Parent.FullName;
// This will get the current PROJECT directory
string projectDirectory = Directory.GetParent(workingDirectory).Parent.Parent.FullName;
You can try one of this two methods.
string startupPath = System.IO.Directory.GetCurrentDirectory();
string startupPath = Environment.CurrentDirectory;
Tell me, which one seems to you better
If a project is running on an IIS express, the Environment.CurrentDirectory could point to where IIS Express is located ( the default path would be C:\Program Files (x86)\IIS Express ), not to where your project resides.
This is probably the most suitable directory path for various kinds of projects.
AppDomain.CurrentDomain.BaseDirectory
This is the MSDN definition.
Gets the base directory that the assembly resolver uses to probe for assemblies.
The proper1 way to get the root folder of a C# project is to leverage the [CallerFilePath] attribute to obtain the full path name of a source file, and then subtract the filename plus extension from it, leaving you with the path to the project.
Here is how to actually do it:
In the root folder of your project, add file ProjectSourcePath.cs with the following content:
internal static class ProjectSourcePath
{
private const string myRelativePath = nameof(ProjectSourcePath) + ".cs";
private static string? lazyValue;
public static string Value => lazyValue ??= calculatePath();
private static string calculatePath()
{
string pathName = GetSourceFilePathName();
Assert( pathName.EndsWith( myRelativePath, StringComparison.Ordinal ) );
return pathName.Substring( 0, pathName.Length - myRelativePath.Length );
}
}
The string? requires a pretty late version of C# with #nullable enable; if you don't have it, then just remove the ?.
The Assert() function is my own; you can replace it with your own, or omit it, if you like living your life dangerously.
The function GetSourceFilePathName() is defined as follows:
using System.Runtime.CompilerServices
public static string GetSourceFilePathName( [CallerFilePath] string? callerFilePath = null ) //
=> callerFilePath ?? "";
Once you have the above, you can use it as follows:
string projectSourcePath = ProjectSourcePath.Value;
1 'proper' as in: fool-proof; sure-fire; without presumptions; not being held together by shoestrings; not bound to work for some projects but fail for others; not likely to horribly break without a warning when you change unrelated things; etc.
This will also give you the project directory by navigating two levels up from the current executing directory (this won't return the project directory for every build, but this is the most common).
System.IO.Path.GetFullPath(#"..\..\")
Of course you would want to contain this inside some sort of validation/error handling logic.
If you want ot know what is the directory where your solution is located, you need to do this:
var parent = Directory.GetParent(Directory.GetCurrentDirectory()).Parent;
if (parent != null)
{
var directoryInfo = parent.Parent;
string startDirectory = null;
if (directoryInfo != null)
{
startDirectory = directoryInfo.FullName;
}
if (startDirectory != null)
{ /*Do whatever you want "startDirectory" variable*/}
}
If you let only with GetCurrrentDirectory() method, you get the build folder no matter if you are debugging or releasing. I hope this help! If you forget about validations it would be like this:
var startDirectory = Directory.GetParent(Directory.GetCurrentDirectory()).Parent.Parent.FullName;
Based on Gucu112's answer, but for .NET Core Console/Window application, it should be:
string projectDir =
Path.GetFullPath(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, #"..\..\.."));
I'm using this in a xUnit project for a .NET Core Window Application.
If you really want to ensure you get the source project directory, no matter what the bin output path is set to:
Add a pre-build event command line (Visual Studio: Project properties -> Build Events):
echo $(MSBuildProjectDirectory) > $(MSBuildProjectDirectory)\Resources\ProjectDirectory.txt
Add the ProjectDirectory.txt file to the Resources.resx of the project (If it doesn't exist yet, right click project -> Add new item -> Resources file)
Access from code with Resources.ProjectDirectory.
This solution works well for me, on Develop and also on TEST and PROD servers with ASP.NET MVC5 via C#:
var projectDir = Path.GetDirectoryName(AppDomain.CurrentDomain.BaseDirectory);
If you need project directory in project configuration file use:
$(ProjectDir)
I was looking for this too. I've got a project that runs HWC, and I'd like to keep the web site out of the app tree, but I don't want to keep it in the debug (or release) directory. FWIW, the accepted solution (and this one as well) only identifies the directory the executable is running in.
To find that directory, I've been using
string startupPath = System.IO.Path.GetFullPath(".\\").
using System;
using System.IO;
// Get the current directory and make it a DirectoryInfo object.
// Do not use Environment.CurrentDirectory, vistual studio
// and visual studio code will return different result:
// Visual studio will return #"projectDir\bin\Release\netcoreapp2.0\", yet
// vs code will return #"projectDir\"
var currentDirectory = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);
// On windows, the current directory is the compiled binary sits,
// so string like #"bin\Release\netcoreapp2.0\" will follow the project directory.
// Hense, the project directory is the great grand-father of the current directory.
string projectDirectory = currentDirectory.Parent.Parent.Parent.FullName;
I had a similar situation, and after fruitless Googles, I declared a public string, which mods a string value of the debug / release path to get the project path. A benefit of using this method is that since it uses the currect project's directory, it matters not if you are working from a debug directory or a release directory:
public string DirProject()
{
string DirDebug = System.IO.Directory.GetCurrentDirectory();
string DirProject = DirDebug;
for (int counter_slash = 0; counter_slash < 4; counter_slash++)
{
DirProject = DirProject.Substring(0, DirProject.LastIndexOf(#"\"));
}
return DirProject;
}
You would then be able to call it whenever you want, using only one line:
string MyProjectDir = DirProject();
This should work in most cases.
Another way to do this
string startupPath = System.IO.Directory.GetParent(#"./").FullName;
If you want to get path to bin folder
string startupPath = System.IO.Directory.GetParent(#"../").FullName;
Maybe there are better way =)
Yet another imperfect solution (but perhaps a little closer to perfect than some of the others):
protected static string GetSolutionFSPath() {
return System.IO.Directory.GetParent(System.IO.Directory.GetCurrentDirectory()).Parent.Parent.FullName;
}
protected static string GetProjectFSPath() {
return String.Format("{0}\\{1}", GetSolutionFSPath(), System.Reflection.Assembly.GetExecutingAssembly().GetName().Name);
}
This version will return the current projects' folder even if the current project is not the Startup Project for the solution.
The first flaw with this is that I've skipped all error checking. That can be fixed easy enough but should only be a problem if you're storing your project in the root directory for the drive or using a junction in your path (and that junction is a descendant of the solution folder) so this scenario is unlikely. I'm not entirely sure that Visual Studio could handle either of these setups anyway.
Another (more likely) problem that you may run into is that the project name must match the folder name for the project for it to be found.
Another problem you may have is that the project must be inside the solution folder. This usually isn't a problem but if you've used the Add Existing Project to Solution option to add the project to the solution then this may not be the way your solution is organized.
Lastly, if you're application will be modifying the working directory, you should store this value before you do that because this value is determined relative to the current working directory.
Of course, this all also means that you must not alter the default values for your projects' Build->Output path or Debug->Working directory options in the project properties dialog.
Try this, its simple
HttpContext.Current.Server.MapPath("~/FolderName/");
string projPath = Path.GetFullPath(#"..\..\..\");
Console.WriteLine(projPath);
This consistently works well for me. Give it a go.
After I had finally finished polishing my first answer regarding the us of public strings to derive an answer, it dawned on me that you could probably read a value from the registry to get your desired result. As it turns out, that route was even shorter:
First, you must include the Microsoft.Win32 namespace so you can work with the registry:
using Microsoft.Win32; // required for reading and / or writing the registry
Here is the main code:
RegistryKey Projects_Key = Registry.CurrentUser.OpenSubKey(#"SOFTWARE\Microsoft\VisualStudio\9.0", false);
string DirProject = (string)Projects_Key.GetValue(#"DefaultNewProjectLocation");
A note on this answer:
I am using Visual Studio 2008 Professional Edition. If you are using another version, (i.e. 2003, 2005, 2010; etc.), then you mayt have to modify the 'version' part of the SubKey string (i.e. 8.0, 7.0; etc.).
If you use one of my answers, and if it is not too much to ask, then I would like to know which of my methods you used and why. Good luck.
dm
Use this to get the Project directory (worked for me):
string projectPath =
Directory.GetParent(Directory.GetCurrentDirectory()).Parent.FullName;
I have used following solution to get the job done:
string projectDir =
Path.GetFullPath(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, #"..\.."));
Try:
var pathRegex = new Regex(#"\\bin(\\x86|\\x64)?\\(Debug|Release)$", RegexOptions.Compiled);
var directory = pathRegex.Replace(Directory.GetCurrentDirectory(), String.Empty);
This is solution different from the others does also take into account possible x86 or x64 build.
(Because 22 answers are not enough... here's one more....)
Mike Nakis posted a great answer, to which I added a few enhancements. This is just a slightly spiffed up version of his very nice code.
As Mike pointed out, this class file must be in the root of the project.
I did not run into any problems with the below, but perhaps there are nuances I'm not aware of. YMMV.
using System.IO;
using System.Runtime.CompilerServices;
namespace Whatever
{
internal static class ProjectPathInfo
{
public static string CSharpClassFileName = nameof(ProjectPathInfo) + ".cs";
public static string CSharpClassPath;
public static string ProjectPath;
public static string SolutionPath;
static ProjectPathInfo() {
CSharpClassPath = GetSourceFilePathName();
ProjectPath = Directory.GetParent(CSharpClassPath)!.FullName;
SolutionPath = Directory.GetParent(ProjectPath)!.FullName;
}
private static string GetSourceFilePathName( [CallerFilePath] string? callerFilePath = null ) => callerFilePath ?? "";
}
}
Ok, 2021, a bit late to the party... but very annoyed by all possibilities I found in many projects:
bin/Debug
bin/x86/Debug
bin/Debug/net5.0-windows
...
Come on... I just need a one-liner (or almost) to address some files in test units; I need to use it on all past, current, (maybe future) projects.
So, if the project name is the same of relative folder which it lies in:
use the assembly name to pick project root folder name;
go back until that name is found.
Code sample:
string appName = Assembly.GetExecutingAssembly().GetName().Name;
var dir = new DirectoryInfo(Environment.CurrentDirectory);
while (dir.Name != appName) {
dir = Directory.GetParent(dir.FullName);
}
return dir.FullName;
The best solution
string PjFolder1 =
Directory.GetParent(AppDomain.CurrentDomain.BaseDirectory).
Parent.Parent.FullName;
Other solution
string pjFolder2 = Path.GetDirectoryName(Path.GetDirectoryName(Path.GetDirectoryName(
System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase)));
Test it, AppDomain.CurrentDomain.BaseDirectory worked for me on past project, now I get debug folder .... the selected GOOD answer just NOT WORK!.
//Project DEBUG folder, but STILL PROJECT FOLDER
string pjDebugFolder = AppDomain.CurrentDomain.BaseDirectory;
//Visual studio folder, NOT PROJECT FOLDER
//This solutions just not work
string vsFolder = Directory.GetCurrentDirectory();
string vsFolder2 = Environment.CurrentDirectory;
string vsFolder3 = Path.GetFullPath(".\\");
//Current PROJECT FOLDER
string ProjectFolder =
//Get Debug Folder object from BaseDirectory ( the same with end slash)
Directory.GetParent(pjDebugFolder).
Parent.//Bin Folder object
Parent. //Project Folder object
FullName;//Project Folder complete path
This works on VS2017 w/ SDK Core MSBuild configurations.
You need to NuGet in the EnvDTE / EnvDTE80 packages.
Do not use COM or interop. anything.... garbage!!
internal class Program {
private static readonly DTE2 _dte2;
// Static Constructor
static Program() {
_dte2 = (DTE2)Marshal.GetActiveObject("VisualStudio.DTE.15.0");
}
private static void FindProjectsIn(ProjectItem item, List<Project> results) {
if (item.Object is Project) {
var proj = (Project) item.Object;
if (new Guid(proj.Kind) != new Guid(Constants.vsProjectItemKindPhysicalFolder))
results.Add((Project) item.Object);
else
foreach (ProjectItem innerItem in proj.ProjectItems)
FindProjectsIn(innerItem, results);
}
if (item.ProjectItems != null)
foreach (ProjectItem innerItem in item.ProjectItems)
FindProjectsIn(innerItem, results);
}
private static void FindProjectsIn(UIHierarchyItem item, List<Project> results) {
if (item.Object is Project) {
var proj = (Project) item.Object;
if (new Guid(proj.Kind) != new Guid(Constants.vsProjectItemKindPhysicalFolder))
results.Add((Project) item.Object);
else
foreach (ProjectItem innerItem in proj.ProjectItems)
FindProjectsIn(innerItem, results);
}
foreach (UIHierarchyItem innerItem in item.UIHierarchyItems)
FindProjectsIn(innerItem, results);
}
private static IEnumerable<Project> GetEnvDTEProjectsInSolution() {
var ret = new List<Project>();
var hierarchy = _dte2.ToolWindows.SolutionExplorer;
foreach (UIHierarchyItem innerItem in hierarchy.UIHierarchyItems)
FindProjectsIn(innerItem, ret);
return ret;
}
private static void Main() {
var projects = GetEnvDTEProjectsInSolution();
var solutiondir = Path.GetDirectoryName(_dte2.Solution.FullName);
// TODO
...
var project = projects.FirstOrDefault(p => p.Name == <current project>);
Console.WriteLine(project.FullName);
}
}
I didn't see a solution by using string.Join and string.Split + SkipLast 4 elements, so here it is.
string projectDir =
string.Join('/', AppDomain.CurrentDomain.BaseDirectory
.Split(new char[] { '/' })
.SkipLast(4));
/* /home/freephoenix888/Programming/csharpProject/bin/Debug/net7.0/csharpProject */
Console.WriteLine(Environment.CurrentDirectory);
/* /home/freephoenix888/Programming/csharpProject/ */
Console.WriteLine(Directory.GetParent(Environment.CurrentDirectory).Parent.Parent.Parent.FullName);
Try:
{
OpenFileDialog fd = new OpenFileDialog();
fd.Multiselect = false;
fd.Filter = "Image files (*.bmp, *.jpg)|*.bmp;*.jpg|All files (*.*)|*.*";
if (fd.ShowDialog() == true)
{
if (fd.CheckFileExists)
{
var fileNameToSave = GetTimestamp(DateTime.Now) + Path.GetExtension(fd.FileName);
var pathRegex = new Regex(#"\\bin(\\x86|\\x64)?\\(Debug|Release)$", RegexOptions.Compiled);
var directory = pathRegex.Replace(Directory.GetCurrentDirectory(), String.Empty);
var imagePath = Path.Combine(directory + #"\Uploads\" + fileNameToSave);
File.Copy(fd.FileName, imagePath);
}
}
}
catch (Exception ex)
{
throw ex;
}
this is the code for uploading image into wpf upload directory
Directory.GetParent(Directory.GetCurrentDirectory()).Parent.Parent.Parent.Parent.FullName
Will give you the project directory.