I want to get the application bin/debug-path

Question

0.00/5 (No votes)

See more:

I want to get the Application Bin/Debug-Path during DesignTime

With Google I found several entries (for example an StackOverFlow) but none of them are working ...

What I have tried:

Application.CommonAppDataPath
Application.ExecutablePath
Application.StartupPath
Application.LocalUserAppDataPath
Assembly.GetEntryAssembly.CodeBase
Directory.GetCurrentDirectory
AppDomain.CurrentDomain.BaseDirectory
My.Application.Info.DirectoryPath

None of them above deliver the right path ... :(

Posted 5-Jul-17 0:17am

Ralf Meier

Updated 6-Jul-17 0:44am

v3

Add a Solution

Comments

Richard MacCutchan 5-Jul-17 6:43am

It depends on where you want to reference the path. Perhaps you could explain exactly what you are trying to do.

Ralf Meier 5-Jul-17 6:48am

I want to save some data, generated by a Component during DesignTime, into this path.
I know that the Designer itself could store the data of a Component into the Designer-Script of the Form where it is placed on but I want to have it Independent.

But your question is not quiet clear for me - what Information do you need ?

Richard MacCutchan 5-Jul-17 7:32am

Sorry, but I am still not clear. The project properties contains the relative path to bin\Debug, but I am not sure how you address that in the designer. In C++ it is fairly simple as all these values are macros that can be accessed by shell commands. C# and VB.NET do not appear to have the same facility, unless you can somehow access the properties via the Visual Studio COM interface using a script.

Ralf Meier 5-Jul-17 8:24am

I think you understood what I mean (or want to know).
My Application is stored under :
C:\Users\myName\Documents\Visual Studio 2013\Projects\myProject\MyProject
So the path I want to get is :
C:\Users\myName\Documents\Visual Studio 2013\Projects\myProject\MyProject\bin\Debug

But none of the articles I found and the namespaces I tried deliver this path - I also will be glad if I get the Application-path. The sub-path "bin\debug" could be added by constant ...

Richard MacCutchan 5-Jul-17 8:49am

Can you just use the path "bin\Debug", since that should be relative to your project directory?

Ralf Meier 5-Jul-17 13:18pm

I want to have it relative to my Project-directory ... but also my Project-directory is nowhere to get (as a variable or something like that) ...

Dave Kreskowiak 5-Jul-17 11:03am

At design time, there is no such thing as the "bin\Debug" folder. If the app has never been compiled, it just doesn't exist.

Also, you're describing something that should never be done at design time. Your component should NEVER create a data file at design time. This file will not be part of the project files and will not be copied to the target Debug or Release folder with the code when it is compiled.

At best, you should be putting this generated data as code in a "designer generated" code file.

Ralf Meier 5-Jul-17 13:16pm

That is the reason why I want to write it to the "bin\Debug"- or "bin\Release"-folder.
But ... because Visual Studio knows where to write the compiled Project-parts I supposed that there is a way to use that inside my Application.

Dave Kreskowiak 5-Jul-17 13:22pm

That is NOT the reason. That's what you WANT to do, but it isn't logical at all.

The problem with your chosen method is that the code may only be executed once, at design time, but the data may not even be written because the target folder doesn't exist. The target folder can also be cleaned out, destroying the data.

The entire point is if this is data that is to be generated, it MUST be generated at run-time, not design-time.

What you are attempting to do is illogical for the application design process because the target folder may not exist at all and impractical because the data can easily be destroyed just by building the application!

You seriously need to take a closer look at what you're doing with this data and why.

Ralf Meier 5-Jul-17 13:41pm

What I want to do is to create a component which provides some Properties to the controls on that form where the component is placed on.
One of this Properties is a List (of string) which allows the selection. The content from this List comes out of the component and should only be created and/or modified at DesignTime. This content must be common for all possible other instances of this component on other Forms inside the same project.
That was the reason, why I decided to do it like this.
The idea, to use the "bin\Debug"- or "bin\Release"-folder came, because at this place finally the ready-compiled Application is to be found (and also necessary DLL's and so on) - so why not place this data-file at the same point because now all parts are together.
If I use the Application (Runtime-mode) I check the Application.StartupPath for this file - my application is able to check this ...

So ... am I really wrong with my thoughts ?

Dave Kreskowiak 5-Jul-17 14:14pm

What you're talking about is a Extender Provider Objects[^]. It's a control that extends other controls, adding new properties and logic to them.

Your data needs to be in designer generated code, which the Designer attributes[^] provides for you. It's the only way your data is going to make it into the application in a reliable manner.

Ralf Meier 5-Jul-17 15:22pm

As I wrote before :
I know all the parts around the Component, providing Properties to other Controls, serializing those provided Properties and so. Most of this is currently realized and still working.
But - all the information actually are stored in the Designer-Script of the Form where the Component belongs to - that means that if I want to use the same on another Form all common Information must be created again. That's why I thought about (for this Component) a Project-wide storage of common information - so each Instance of this Component-type can access the same data-base ...

Apologize if not all of this is clear from the beginning of this "discussion" ...

Dave Kreskowiak 5-Jul-17 15:48pm

I didn't catch that from the discussion. It would appear that your going to have to create a custom serialization tool to put your data into a static class, independent of the DesignerSerializationVisibility attribute.

I don't have an example because I've never seen it done, nor have I done it myself.

Ralf Meier 5-Jul-17 16:00pm

... but you understand my goal ?
Of course ... it is possible that there is nothing comparable to be found. It is an idea (all starts with an idea ;-))
Perhaps, if I could finish it, I write an article about it in CP.
In the moment I stuck with this "simple" part - I can serialize it but not automaticly at the place I want to have it.
That's the reason why I ask for the Project-path as a variable (or something like this). I don't want to write the path as a constant ...

Dave Kreskowiak 5-Jul-17 16:14pm

I understand all right. The problem with what you're trying to do is you're trying to get a path from Visual Studio. There is no "environment" variable that gives you that path. It only really exists at compile time.

That path also changes depending on if you're building a Debug build or a Release build. It can also change if additional Configurations are made. The path will probably no longer be of the format \bin\Debug or \bin\Release, possibly \bin\x86\Debug or \bin\x64\Release or whatever, depending on configuration names.

Now, in order to get the path from Visual Studio, your code has to be written to get the path from Visual Studio, forever tying your project to Visual Studio, possibly specific versions of it because of changes in the DTE (Visual Studio) object model.

That's a really bad idea.

Ralf Meier 5-Jul-17 16:02pm

Put the data into a static class could also be a way - but I have no idea how to realize that ...

Dave Kreskowiak 5-Jul-17 16:21pm

Neither do I. This is where a bunch of research comes in.

I would probably start with:
Custom DesignerSerializationVisibilityAttribute - Google Search[^]
Creating Custom Editors and Designers[^]
and
Designer Serialization Overview[^]

Ralf Meier 6-Jul-17 3:58am

Thanks for the Link's ... but with most of them I'm familiar ...
My only problem is where (and perhaps how) to store the "common" data ...

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Ralf Meier · Accepted Answer · 2017-07-06T00:44:00

Solution 1

Not the whole Solution but a part of it.
This code-snippet gives the Project-path :

VB

Dim dte As EnvDTE.DTE = System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE")
Dim dir As String = Path.GetDirectoryName(dte.Solution.FullName)

To get it work it is necessary to add a reference to "Microsoft.Development Environment"

see also : Referencing the DTE Object[^]

Posted 6-Jul-17 0:44am

Ralf Meier

Comments

Richard MacCutchan 6-Jul-17 7:13am

Well done finding it. In C++ they call it the Project Model.

Ralf Meier 6-Jul-17 8:17am

Thanks Richard (also für your vote) ... it was a hard way to go ...

Richard MacCutchan 6-Jul-17 8:26am

Quote from Windows Programming by Charles Petzold, "No one said it was easy". :)