Alan Hemmings

My feedback

  1. 9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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. 814 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    25 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Alan Hemmings commented  · 

    I believe that referencing linqpad files makes more sense that cs files, e.g.
    #include MySettings.linq
    #include MyDTOs.linq

    Alan Hemmings commented  · 

    This is never going to be done.

    Perhaps what we need to do, is ask Joe ... "How much?" and we start a kickstarter campaign to make it happen?

    :)

    Happy to pay an extra licence for being able to use this at work across multiple scripts. That would ensure that random kiddy developers who are using Linqpad for playing with coding don't use the mutli-script version and only serious teams would purchase the team-support upgrade.

    cmon, let's make this happen!

    Alan Hemmings commented  · 

    Id rather include another .linq file instead of a .cs, that way if the referenced file was in program format, then the main for the included file will be ingnored, and I could use the main (of the included linq) file, as a means of running some simple tests when working on the script.To edit the included file, I'd simply double click it, and make changes, run some code as a test, and hit save, bosh...done.

    Alan Hemmings supported this idea  · 
    Alan Hemmings commented  · 

    I just hit a brick wall trying to use linqpad instead of powershell and nant as a built tool, and need to be able to either pass DTO's to a script, (assuming the DTO is in a referenced assembly), or I need to be able to include a script, so that I don't have to repeat myself. With this feature I could use linqpad as a build tool, currently as it stands, I cannot use it for any resonable size project. I could replace powershell, Ruby, Nant ... all with Linqpad, please please please add this feature! ;-D (Util.Run is a good start, but is buggy. Include makes far more sense, alternatively be able to pass proper objects between scripts, so that we don't have to parse strings to objects all the time in Main(string[] args). Linqpad is soooo close to being able to be more useful that powershell!

  3. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Alan Hemmings shared this idea  · 
  4. 141 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Alan Hemmings commented  · 

    Noooo, (lying on the floor crying and sobbing that Lingpad 5 did not include this feature!) why, why? why is this world so crule? <sob> <sob> <sob> Now I'm going to have to learn ruby, or worse, powershell. ;-D

    Alan Hemmings commented  · 

    Just found that this is a duplicate of duplicate of http://linqpad.uservoice.com/forums/18302-linqpad-feature-suggestions/suggestions/211578-include-another-cs-file-s-in-a-linq-file

    (That suggestion already has 343 votes, so will be moving my votes off this, onto that one. )

    Alan Hemmings commented  · 

    Also discovered today that the code you place in My Extensions actually lives in c:\users\ { you } \ my documents \ linqpad plugins \ MyExtensions.FW30.linq ( eurgh! ) These are specific to a user and can't be included in source control, or shared.

    A temporay fix perhaps could be to have the "myExtensions.linq" file live in the root folder where their linq files reside. (the folder that the user selects when he clicks "organise"? That would allow us to check in shared project extensions into source control.

    Alan Hemmings commented  · 

    Totally agree Bent! I'm using linqpad together with nant scripts as build tools instead of using powershell in order to keep our technology stack really thin, and I keep hitting the "wall" as you describe. Allowing linqpad scripts to reference scripts they need instead of requiring that the users MyExtensions are flooded with every possible extension means that the scripts can be keep isolated and more maintanable. (Seperation of concerns) My Extentions is great, but you start accumulating technical debt really quickly on a large project. Thanks for the suggestion! Would have used more votes if I could ;-D

    Alan Hemmings supported this idea  · 
  5. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
  6. 39 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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

  7. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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  · 
  8. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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  · 
  9. 335 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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.

    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.

  10. 98 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    8 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    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.

  11. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: facebook google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  LINQPad Feature Suggestions  ·  Flag idea as inappropriate…  ·  Admin →
    Alan Hemmings commented  · 

    (forgot to mention that the main purpose is to be able to have an option to use or install a free decompiler... any one. Otherwise it pushes up the price of using linqpad, which is just super sweet.) Quite happy for this also to be a premium feature <nudge, nudge> ;-D

    Alan Hemmings shared this idea  · 

Feedback and Knowledge Base