none
layout of programs in C# RRS feed

  • Question

  • I have been a long time programmer in delphi (30+years). Have some libraries (units in Delphi) that are used in most of my programs, others are just within a single program. I know c# knows where it's system files are located, but how do I set up my "shared" multi-project files and then refer to them with using statements? Granted I've only been working with c# for a couple of weeks (so this question might be premature) but have worked through 2 books so far and they haven't addressed this. All the files in the examples are all in the same namespaces--that of the particular example program. I'm trusting that end user installation of c# programs will become clear later and will be manageable. Thanks in advance for any clarifications anybody can provide.

    Friday, March 2, 2018 9:40 PM

Answers

  • One idea is to create a install program that installs common class/DLL files into the GAC.

    There are many articles out there to choice from, this is one of them.

    https://www.onlinebuff.com/article_how-to-deploy-an-assembly-into-gacglobal-assembly-cache-_38.html


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:51 PM
    Friday, March 2, 2018 9:55 PM
    Moderator
  • You can break up your code into different projects. Generally you have a single executable program and any number of additional class library projects where the bulk of the code resides. A class library is equivalent to a unit in Pascal. Many applications have, for example, a business library, data library and service library.

    For sharing across solutions there are several options. You could store the files in the GAC like Karen mentioned. This is useful when you need to support multiple versions of the same assembly across multiple projects. This is equivalent to the shared system DLLs that are common in native code. There are some disadvantages to this approach though. The biggest is that you have to be an admin to install to the GAC. Another is that you have to strongly name your assemblies (GAC requires this). Yet another issue is that you have no way of knowing what code is relying on the assembly so you really can never "uninstall" it. However it does have the advantage of hotfixing. If you later find an issue in the code and want to update all your apps you need only update the version in the GAC and all apps will use the new version. Of course you wouldn't do this for anything other than fixing something that is broken. In all other cases you'd create a new version anyway.

    Another option to share code and what has seen to become the most popular these days is simply packaging the code up into a NuGet package. VS supports NuGet implicitly and it is great way to grab dependencies. The bulk of ASP.NET ships this way and .NET Core has gone completely this way. The advantage here is that each of your projects gets to decide which version it wants to use and so you can be using different versions for different apps. Another advantage is that it makes it clear what you're dependencies are and doesn't require any extra installs of libraries or anything. Everything gets pulled from NuGet at build time.

    NuGet does have disadvantages as well. Firstly each app has its own copy of the binaries. Some see this as a disadvantage but given the size of assemblies and the large drives I don't believe it really is. Another disadvantage is that you have to host the packages somewhere. NuGet allows you to host your packages  but it is public facing. If you have private packages that you don't want others to have then you need to set up your own repo. If you're using TFS then it has one built in. Alternatively you can use a file share. Another disadvantage is hotfixes. If you find a critical bug in the code then you'd have to push a new package and then update all the code that references it. In a prod environment this could be done using xcopy deployment but at some point you'll have to update the reference and recompile your code.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    Friday, March 2, 2018 10:10 PM
    Moderator
  • but how do I set up my "shared" multi-project files and then refer to them with using statements?

    You can create a classlib project, that creates a DLL, that you can set reference to the DLL in a project. As long as the DLL is in the same folder as the standalone executable, an programname.exe file, then .NET will find the DLL, because .NET DLL(s) do not need to be registered with the O/S.

    The programname.exe and the DLL(s) are in the Bin folder, if you look at the Visual Studio folder structure for a given VS project.

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:55 PM
    • Unmarked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    Friday, March 2, 2018 10:17 PM
  • You say that there is only one namespace. You have the option of putting some of the classes in separate Class Libraries but everything would still be one application. In Visual Studio you will have separate projects for the main executable and each Class Library.

    If all of that is true then the Class Libraries are not shared and do not need to be in the GAC. If you want details of that then see Global Assembly Cache; it says:

    The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer.

    And storing in the GAC is a bit more work; that page also says:

    Assemblies deployed in the Global Assembly Cache must have a strong name.

    I can understand that it is often difficult to know what terminology to use and we can't be sure what you mean by "multi-project files". If any of the preceding indicates I misunderstand then say so.

    As for "using statements" I think the answer you are looking for is that you will need to add a reference for each Class Library that an executable or Class Library project uses. The using statement does nothing more than specify a default namespace for classes.

    Oh, okay now I see that you are saying that all the samples in the books have used a single namespace but you are implying that you intend to create multiple applications that share code. So the GAC might be relevant.

    One more thing to understand is that Microsoft provides two ways to install (deploy/publish/set up) applications. For .Net it is usually ClickOnce but the classic installer can be sued sometimes; it is officialy called the Windows Installer but sometimes it is called msi installer since it uses a msi file as a "database".



    Sam Hobbs
    SimpleSamples.Info


    Saturday, March 3, 2018 9:09 PM

All replies

  • One idea is to create a install program that installs common class/DLL files into the GAC.

    There are many articles out there to choice from, this is one of them.

    https://www.onlinebuff.com/article_how-to-deploy-an-assembly-into-gacglobal-assembly-cache-_38.html


    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:51 PM
    Friday, March 2, 2018 9:55 PM
    Moderator
  • You can break up your code into different projects. Generally you have a single executable program and any number of additional class library projects where the bulk of the code resides. A class library is equivalent to a unit in Pascal. Many applications have, for example, a business library, data library and service library.

    For sharing across solutions there are several options. You could store the files in the GAC like Karen mentioned. This is useful when you need to support multiple versions of the same assembly across multiple projects. This is equivalent to the shared system DLLs that are common in native code. There are some disadvantages to this approach though. The biggest is that you have to be an admin to install to the GAC. Another is that you have to strongly name your assemblies (GAC requires this). Yet another issue is that you have no way of knowing what code is relying on the assembly so you really can never "uninstall" it. However it does have the advantage of hotfixing. If you later find an issue in the code and want to update all your apps you need only update the version in the GAC and all apps will use the new version. Of course you wouldn't do this for anything other than fixing something that is broken. In all other cases you'd create a new version anyway.

    Another option to share code and what has seen to become the most popular these days is simply packaging the code up into a NuGet package. VS supports NuGet implicitly and it is great way to grab dependencies. The bulk of ASP.NET ships this way and .NET Core has gone completely this way. The advantage here is that each of your projects gets to decide which version it wants to use and so you can be using different versions for different apps. Another advantage is that it makes it clear what you're dependencies are and doesn't require any extra installs of libraries or anything. Everything gets pulled from NuGet at build time.

    NuGet does have disadvantages as well. Firstly each app has its own copy of the binaries. Some see this as a disadvantage but given the size of assemblies and the large drives I don't believe it really is. Another disadvantage is that you have to host the packages somewhere. NuGet allows you to host your packages  but it is public facing. If you have private packages that you don't want others to have then you need to set up your own repo. If you're using TFS then it has one built in. Alternatively you can use a file share. Another disadvantage is hotfixes. If you find a critical bug in the code then you'd have to push a new package and then update all the code that references it. In a prod environment this could be done using xcopy deployment but at some point you'll have to update the reference and recompile your code.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    Friday, March 2, 2018 10:10 PM
    Moderator
  • but how do I set up my "shared" multi-project files and then refer to them with using statements?

    You can create a classlib project, that creates a DLL, that you can set reference to the DLL in a project. As long as the DLL is in the same folder as the standalone executable, an programname.exe file, then .NET will find the DLL, because .NET DLL(s) do not need to be registered with the O/S.

    The programname.exe and the DLL(s) are in the Bin folder, if you look at the Visual Studio folder structure for a given VS project.

    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:55 PM
    • Unmarked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    • Marked as answer by JoeFromDelphi Tuesday, March 6, 2018 3:58 PM
    Friday, March 2, 2018 10:17 PM
  • You say that there is only one namespace. You have the option of putting some of the classes in separate Class Libraries but everything would still be one application. In Visual Studio you will have separate projects for the main executable and each Class Library.

    If all of that is true then the Class Libraries are not shared and do not need to be in the GAC. If you want details of that then see Global Assembly Cache; it says:

    The Global Assembly Cache stores assemblies specifically designated to be shared by several applications on the computer.

    And storing in the GAC is a bit more work; that page also says:

    Assemblies deployed in the Global Assembly Cache must have a strong name.

    I can understand that it is often difficult to know what terminology to use and we can't be sure what you mean by "multi-project files". If any of the preceding indicates I misunderstand then say so.

    As for "using statements" I think the answer you are looking for is that you will need to add a reference for each Class Library that an executable or Class Library project uses. The using statement does nothing more than specify a default namespace for classes.

    Oh, okay now I see that you are saying that all the samples in the books have used a single namespace but you are implying that you intend to create multiple applications that share code. So the GAC might be relevant.

    One more thing to understand is that Microsoft provides two ways to install (deploy/publish/set up) applications. For .Net it is usually ClickOnce but the classic installer can be sued sometimes; it is officialy called the Windows Installer but sometimes it is called msi installer since it uses a msi file as a "database".



    Sam Hobbs
    SimpleSamples.Info


    Saturday, March 3, 2018 9:09 PM