Home

How can I use the same project in `LINQPad` and in` Visual Studio`?

Question.
How can I use the same project in LINQPad and inVisual Studio?

Description.
I have created a project in LINQPad that represents a specific structure of classes.
How to make sure that I can open the same project in LINQPad and inVisual Studio, add and remove classes, add and remove methods in classes, change methods.

If I understand correctly the section LINQPad FAQ. Can I access internal types of assemblies that I reference?, then I can only work according to the following scheme:
- create a project in Visual Studio;
- create DLL from the project in Visual Studio;
- connect DLL in LINQPad;
- Result: in LINQPad I can only use DLL methods.
I cannot add and remove classes, add and remove methods in classes, modify DLL methods.

Questions.
1. How to use the same project in LINQPad and inVisual Studio?
2. Do I understand correctly the principles of work in LINQPad withVisual Studio described in the LINQPad FAQ. Can I access internal types of assemblies that I reference??

Used.
- LINQPad - 6.9.15x64;
- Visual Studio - 2019. Community.

Comments

  • How to use the same project in LINQPad and inVisual Studio?

    If you are expecting to have one source file that you can edit in either LinqPad or visual studio, then I don't believe that is possible.

    LinqPad uses linq files and VS uses cs and csproj files.

    Do I understand correctly the principles of work in LINQPad withVisual Studio described in the LINQPad FAQ. Can I access internal types of assemblies that I reference??

    Yes.

    Linqpad can use other dlls produced by a Visual Studio project but this is not source code and can not be changed. The restrictions on what you can do with the classes/methods defined in the other dll from inside LinqPad are imposed by the language/dotnet runtime and not the editor and so are pretty much the same as those on in VS (eg if I reference a dll produced by VS project A in another VS project), ie

    Change/Remove classes   : Not possible
    Change/Remove methods   : Not possible
    Add classes             : Possible
    Add methods             : It would be possible to define extension methods 
    

    Note, Extensions methods do not have access to private members/methods unless you use Uncapsulate

    I do quite a lot of my prototyping and testing in Linqpad, but if I want to start using my code in Visual Studio, I just copy the code into cs files and compile them there.
    Occasionally it goes the other way where I want to refactor some cs code but want to use LinqPad and then I need to copy the code from VS to LinqPad.

  • @sgmoore
    In other words, the main purpose of LINQPad is to create some fragments of the application's functionality, test their operation, and then manually transfer them to the main project in VS.
    Am I right?

  • LINQPad is a utility or tool that can be used for many different things, and so I don't think I can say what its main Purpose is.

    I can tell you how I use it.

    Queries

    Nowadays, I very rarely use Microsoft's SQL Server Management Studio or Enterprise Manager either for queries or editing data, preferring to use Linqpad. (I would use Linqpad to issue direct Sql queries, but prefer to use Linq2Sql instead).

    I am asked to do lots of one-off queries and with LinqPad I will probably be half-finished before VS has time to load and that's not even mentioning the advantages of being able to see the results before exporting to csv or excel etc.

    Standalone scripts

    I have a lot of stand-alone scripts that could be made into programs, but there is no need and no advantage in doing so and in quite a few cases would be at a disadvantage outside LinqPad.

    The "Legendary Dump"

    I have referenced LinqPad from a number of full-blown programs just to be able to make use of the wonderful formatting capabilities. Sometimes this is to be displayed in a hosted web-browser control, but quite often it is to produce html which will be emailed.

    Prototyping.
    Not all the queries I do are one-offs, so when I want to I build a new report, I usually like to start in Linqpad until I have it working and then transfer into our main program. (This is similar to your suggested use case, but is only one of many options)

    Checking on generated SQL
    With Linq2Sql, it is important to make keep an eye on the Sql that is generated. For example, recently I had a complicated query written that I was happy and it generated on SQL Statement and I made one minor little change which I would not expected to have much effect, but cause the program to generate an initial query and then one additional query per record returned. Using LinqPad, this information is just one click away, which is a lot handier than firing up and using Sql Profiler.

    All the above is related to work, but I have also used it quite a bit at home, for things like looking at the data stored by third party programs which use Sqlite databases or services that expose their data via webservices etc.

    As you can tell, I am a big fan (Joe, if you are reading thank you once again) and have been using it for over 12 years. Even though I would say most of my queries are not saved, I still have about 2000 that I have decided to keep.

  • @dv_linqpad said:
    In other words, the main purpose of LINQPad is to create some fragments of the application's functionality, test their operation, and then manually transfer them to the main project in VS. Am I right?

    That is a major use-case right now.

    It sounds like what you're looking for is a feature that would allow source files to be shared between LINQPad and a Visual Studio project. This would be possible if the #load directive in LINQPad was enhanced such that it could accept .cs files:

    #load "C:\source\MyProject\SomeClass.cs"
    

    or even:

    #load "C:\source\MyProject\*.cs"
    

    LINQPad would also need to be able to read/write files in a .cs format.

    Is that what you have in mind?

  • @JoeAlbahari said:

    @dv_linqpad said:
    In other words, the main purpose of LINQPad is to create some fragments of the application's functionality, test their operation, and then manually transfer them to the main project in VS. Am I right?

    That is a major use-case right now.

    It sounds like what you're looking for is a feature that would allow source files to be shared between LINQPad and a Visual Studio project. This would be possible if the #load directive in LINQPad was enhanced such that it could accept .cs files:

    #load "C:\source\MyProject\SomeClass.cs"
    

    or even:

    #load "C:\source\MyProject\*.cs"
    

    LINQPad would also need to be able to read/write files in a .cs format.

    Is that what you have in mind?

    If I understood you correctly, then you assume two solutions:
    1. Ability of the #load directive in LINQPad to accept "* .cs" files.
    2. Ability to read / write files in "* .cs" format.

    Then my answer is yes.
    I meant exactly these functions.

    For point "2" I want to add the ability to test the file (F5).
    In other words, LINQPad should work with a project that is created in VS.

    Questions.
    1. And if I'm correct, LINQPad doesn't support these functions?
    2. Do I understand correctly that I can use LINQPad to work with C # only according to the following scheme:
    - I created fragments of the main C # program in LINQPad;
    - tested the code;
    - transferred the code by hand to VS.
    I understand correctly?

  • The new LINQPad beta allows

    #load "C:\source\MyProject\SomeClass.cs"
    

    and:

    #load "C:\source\MyProject\*.cs"
    

    I don't know how much this will help with what you're trying to do, but it should certainly enable some more code-sharing scenarios.

Sign In or Register to comment.