Skip to content

Settings and activity

8 results found

  1. 12 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    I've not used linqpad for a while, ... i've noted over the last few months that occasionally when I have to do something in Linqpad that it's become so unresponsive that it's really no longer worth using linqpad. It takes up to 5 seconds for something to happen when you click things, any things, opening a script, switching between tabs, running a hello world with Console.Write("hello"), you name it, it's around 5 seconds.

    I just assumed it was a known bug and some automatic update would fix it, but no such luck.
    I'm on version 5.26.1 commercial paid licence.

  2. 1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Alan Hemmings shared this idea  · 
  3. 6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 
  4. 42 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    A better solution if the myextension is becoming large, is to move the non domain specific stuff into a utility dll using visual studio, then reference that dll from any script that needs the extended functionality. Also, if you have different projects that require different types of "shared utilities" then include an xcopy (copy) of linqpad in your tools folder of your solution, and create subfolders under each project (each code base) with the project specific extensions you require.

    The only slight downside with this approach is (I think) you will lose the ability to simply double click a linqpad script to launch linqpad, as that will launch the version of linqpad (in it's installed location and it's own extensions) rather than the specific version for each project.

    If you're using linqpad as some type of build tool, then you can get your ps scripts or batch files to run the linqpad scripts using lprun, i.e. run the specific version of linqpad in your solutions tools folder, so that all the paths and extensions are correct (for that specific solution).

    ;-D

  5. 11 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    Good question, sorry I didnt' explain properly. This is probably an extension of the suggestion to be able to automate linqpad so that it can run as part of a build script. Currently there's no simple product on the market or opensource that allows you to securely execute scripts on windows servers, (automatically) as part of a build process, not without severely compromising the servers security or requiring a huge amount of server management skills. There are some enterprise products, but they are such enterprise behemoths it's like shooting a fly with a "cricket" (MIB). Plus, remote desktop can't be automated, you have to manually log in. Use case I envisage is where I need to tweak and test the bits of the script that will execute remotely versus once they're working executing them and parsing results.I don't want to have to open a bunch of remote desktop windows, that's massively unproductive, I simply want to write two lines of code to query machine X, then another line that get's the perf counter from Machine Y, and then compares that to some values stored on machine Z, and if some condition, I want to delete a folder on another machine and fetch some package from source control. I'd want to be able prototype each piece of the script from one software interface, and see everything expressed neatly in front of me in code, as a script, not as "apps on remote desktops". Rule #1, automate repetitive tasks that humans do. If I have to log in to a remote desktop, I need to be logging in, selecting machines, opening apps,clicking buttons, waiting for results, all very time consuming repetitive and subject to human error. A single .linq script, can be code reviewed, can express the intent, and can be automated and then run by team city. w00t! I'm thinking that this would either require a remote execution DSL, for example ServerManager.Execute(OnMachineA, ()=> { my script {); or have a way of having scripts reference each other, [ so that you can give an entire "script" permissions ] then the DSL could perhaps look like var DBDeployResults = ScriptManager.Execute(RemoteMachineX, "GetLatestTestDB.linq"); Sorry for the brain dump. Am thinking that this could massively increase the market for linqpad, potentially any microsoft shop working with team city could then justify putting a linqpad (runner?) on every server that they manage. As the person responsible for sw purchases, I can easily justify pay for a linqpad CI licence for each of our production and test servers. We were managing 17 servers, and paying for 17 linqpad licences to achieve the above would not have battered an eyelid. Just saying... ;-D

    Alan Hemmings shared this idea  · 
  6. 1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    forgot to add, the reverse should also happen when clicking the instant share hyperlink, if it's your instant share, linqpad should open and display the script for editing or running, if it's someone else's then it should download and linqpad should open, and move the downloaded file to the downloads folder (next to shares), and pressing control+shift+u should get latest version of it (assuming my collegue sitting next to me give me the "Ah, just fixed it, you can grab it now" nod! ;-D ) Linqpad should also install support for .linq in chrome so that all this happens automagically, so that it's not just downloaded to my disk.

    Alan Hemmings shared this idea  · 
  7. 338 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    Hi Joe, just read your notes on oreilly, where you ask about output: I'd love for the QueryResult to support something like automapper and automatically MAP the results from the script to my <T> results, for example, perhaps with a:

    public class Top { public double TopX { get; set; } public double TopY { get; set; }}
    List<Top> stats = Query.Run("myquery.linq");
    or
    var stats = Query.Run<List<Top>>("myquery.linq");

    Having the standard error and console still be supported, would allow me to continue to use the approval's library we use for our build steps ( http://approvaltests.sourceforge.net/ ) to (approve) that the build step ran correctly, and then pipe the strongly typed output of that step to the next build step without having to "parse" text or html.

    An error occurred while saving the comment
    Alan Hemmings commented  · 

    re: MikeS -> Oh my gosh, "compile to exe and install as service"
    that is such an awesome idea! (I second that idea)
    (I spent some time yesterday having coffee with a dev friend, he was showing me Scala samples, I was showing him writing the same Scala code in C# with same terseness, from within LinqPad. sweetness ;-D Thanks Joe! My top 3 dev tools, Linqpad, Visual studio, Resharper... in that order. I love the fact that if I'm really pressed for time, have a clean server with no toolage, I can install Linqpad within seconds, and get on with being productive.

  8. 122 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    Alan Hemmings commented  · 

    In order for linqpad to be usable as a deployment tool, in addition to command line interface, we'd need to be able to have seperate linqpad settings (and folder locations) for different projects. For example, when I'm working on a client project I currently have to "set folder" so that linqpad scripts that I write get checked into source control, then when I want to work on my own personal projects, I have to "set folder" again, so that I don't accidentally check in my personal linqpad scripts into my clients project when I'm at home. The same goes for my extensions, and plugins, which should be able to be project (or solution) specific. The suggestion to support multiple "folders" would fix this, as I could choose to add a linq script to either my personal project, or to a specific customer project.