none
How to create custom properties for a c# solution in VS 2015

    Question

  • Hello,

    I need to create a solution level custom property for a C# solution.

    I want the projects under it to be effected.( like a output build path )

    When the same projects would be in another solution, different paths.

    I read about property sheets and property manager but i saw that was only C++.

    Any way to do this for a C# solution?

    Another way to solve the build paths?

    Thanks

    Roy

    Sunday, April 23, 2017 8:51 AM

Answers

  • Perhaps I misunderstand your setup but if you have class libraries then there are only 2 ways to reference them in other projects (the type is irrelevant) - binary or project. Let's assume you have the following projects:

    • L1 - class library, default output dir = {solutiondir}\L1\bin\{configuration}
    • L2 - class library that depends on L1, default output dir = {solutiondir}\L2\bin\{configuration}
    • A1 - Windows app depends on L1, default output dir = {solutiondir}\A1\bin\{configuration}
    • W1 - Web app depends on L2, default output dir = {solutiondir}\W1\bin\{configuration}

    If all the projects are in the same solution then you should be using project references. This allows VS to handle the dependency build logic. Furthermore project references are automatically copied to the output of the dependent project. It doesn't matter where they get built from. So in the above example L1 and L2 build to there appropriate location. When A1 builds L1 will be automatically copied to A1's output directory. When W1 builds L1 and L2 will be automatically copied to W1's output. You don't need to do anything for this scenario.

    If you are using binary references then each project has to explicitly reference the path that it is pulling the binaries from. So if A1 was using a binary reference to L1 then when A1 builds the reference would get copied from L1's output. Even in this case the dependencies are automatically copied to the output folder of the dependent project. Ideally though you're using NuGet to retrieve code outside your solution.

    There are a few cases where this doesn't work:

    1. In the reference properties you can set the option to not copy the assembly local. This is only set when you're working with strongly named assemblies.
    2. If you have an indirect reference to an assembly (eg. config entry) then there is no reference and it won't be copied. This is where post-build events can be used.

    So I don't think you need solution properties for your situation. It should just work with the standard reference system. Have you tried just using references normally and had issues? If so then can you identify the reference relationships you have and what behavior you were seeing?

    • Marked as answer by roypentagon Monday, May 1, 2017 10:40 AM
    Thursday, April 27, 2017 1:42 PM
    Moderator

All replies

  • Hi Roy,

    Welcome to the MSDN forum.

    Refer to your description, your issue is about C# development. Since our forum is to discuss the VS IDE, I will help you move it to the appropriate forum: Visual Studio Languages> Visual C# to seek for a more professional support, thank you for your understanding.

    Best regards,

    Sara


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, April 24, 2017 6:31 AM
  • For me, I will just use the previous ini concept to get all the project read from the ini file or text file.

    You can of course create a app.config or web.config for all your projects to read from the same config file.

    chanmm


    chanmm

    Monday, April 24, 2017 12:49 PM
  • Solutions don't have properties that would impact the projects under them. You'd need to add your own custom property to each project file. You can do that as MSBuild allows you to add properties to the project file as you see fit. Many extensions do just this.

    If you want to influence the MSBuild process then I'd consider creating your own build task that is invoked in the projects you need it for. For simple tasks you can define an inline build task in a .targets file. For more complex solutions then you'll want to create a task assembly that can be installed to MSBuild and called from anywhere.

    If you just want to change path information for projects then consider using environment variables in combination with project build properties instead.

    Michael Taylor
    http://www.michaeltaylorp3.net

    Monday, April 24, 2017 2:37 PM
    Moderator
  • Hello,

    Thank u for your answers,

    About project properties, are they usable by the project output path?

    I mean for example, if i define a property called OUT, will i be able to use it in the project build folder input?

    Thanks,

    Bye

    Tuesday, April 25, 2017 11:24 AM
  • Yes you can use them anywhere in the project file. However the UI support isn't there so you're committing to making changes manually.

    I really question why you're wanting to go this route. In general either absolute or relative paths should solve all your problems. If you want your projects to always build to a specific folder then use an absolute path in your output directory. For relative paths use a relative one. Relative paths can be relative to the project or the solution that contains it. So if you want to have a per-solution structure then (assuming you don't have multiple solutions in the same folder) then a relative path that points back to the solution should be sufficient.

    Env vars are the last option but I've rarely seen those done outside build servers. And that is another thing, build servers tend to set the output directory explicitly. This will override anything you set in the project settings so if you intend to do automated builds then you'll want to use relative paths anyway.

    Tuesday, April 25, 2017 3:14 PM
    Moderator
  • Hello,

    Well, let me explain in more detail my problem.

    We have many projects which in our solution.

    A lot of them are library projects used by other main projects such as exes, services and web sites.

    When compiling the libraries under an exe solution we want the output to be put in the same output folder as the main exe, relative paths worked fine here.

    BUT, since sometime we want to use the same library projects inside web projects, we need the output in that state to be another relative folder since the output of the web site is not the same as those exe solutions.

    In short, we want the output path of the library projects to change, depending on which solution it is used inside.

    That's, why, a solution property would have solved the issue for me. Unfortunately there is no such a thing.

    So, a project property which changes its value according to the solution it is used in is a possible solution for this.

    What do u think?

    Thanks for the help.

    Roy

    Thursday, April 27, 2017 10:46 AM
  • Perhaps I misunderstand your setup but if you have class libraries then there are only 2 ways to reference them in other projects (the type is irrelevant) - binary or project. Let's assume you have the following projects:

    • L1 - class library, default output dir = {solutiondir}\L1\bin\{configuration}
    • L2 - class library that depends on L1, default output dir = {solutiondir}\L2\bin\{configuration}
    • A1 - Windows app depends on L1, default output dir = {solutiondir}\A1\bin\{configuration}
    • W1 - Web app depends on L2, default output dir = {solutiondir}\W1\bin\{configuration}

    If all the projects are in the same solution then you should be using project references. This allows VS to handle the dependency build logic. Furthermore project references are automatically copied to the output of the dependent project. It doesn't matter where they get built from. So in the above example L1 and L2 build to there appropriate location. When A1 builds L1 will be automatically copied to A1's output directory. When W1 builds L1 and L2 will be automatically copied to W1's output. You don't need to do anything for this scenario.

    If you are using binary references then each project has to explicitly reference the path that it is pulling the binaries from. So if A1 was using a binary reference to L1 then when A1 builds the reference would get copied from L1's output. Even in this case the dependencies are automatically copied to the output folder of the dependent project. Ideally though you're using NuGet to retrieve code outside your solution.

    There are a few cases where this doesn't work:

    1. In the reference properties you can set the option to not copy the assembly local. This is only set when you're working with strongly named assemblies.
    2. If you have an indirect reference to an assembly (eg. config entry) then there is no reference and it won't be copied. This is where post-build events can be used.

    So I don't think you need solution properties for your situation. It should just work with the standard reference system. Have you tried just using references normally and had issues? If so then can you identify the reference relationships you have and what behavior you were seeing?

    • Marked as answer by roypentagon Monday, May 1, 2017 10:40 AM
    Thursday, April 27, 2017 1:42 PM
    Moderator
  • Hello,

    Thank u for the answer,

    You are correct, in case of the web project, the referenced projects's assemblies were indeed copied to the output folder

    of the web project.

    The issue was, we wanted to change the default "bin" output folder of the web project between x86 and x64.

    But, as soon as we tried, IIS Express went boom.

    So, in the end we gave up...

    Thanks

    Roy


    Monday, May 1, 2017 10:43 AM