.NET Megathread 3.5: await GetGoodPosts()

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »

LongSack: Jan 17, 2003

raminasi posted:

Why did you think that would fix it? If it's returning before it's done, it's returning before it's done. Doing that on a different thread won't make a difference.

If there's an async call at the bottom, then that's what you want to be using. Do you control the FileManager? Can you create a CopyAsync that exposes the underlying asynchrony?

I see what you're saying. await waits for the task to end, but DownloadFileAsync just returns. I can change it to use the DownloadFile method instead, which should block until the copy is complete, and putting it in a await Task.Run() means the UI thread won't block. I think. Thanks!

Edit: The synchronous version doesn't appear to fire DownloadProgressChanged events

I will have to switch to using FtpWebRequest / FtpWebResponse if i want progress, I guess.

LongSack fucked around with this message at 18:32 on Dec 7, 2018

# ? Dec 7, 2018 16:39

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 02:55

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Just giving all of you soon-to-be-my-best-friends a heads up, I'm moving back into the .NET world after being out of it for years. I'm going from WPF VB.NET circa 2010 into all new and cool C# MVVM/EF, so I'm sure I'll have tonnes of dumb questions as I get further into the details. I had some initial questions:
- I'm seeing a lot of LINQ SQL type stuff, I had thought this was being deprecated? Or was it just folded into a more core library?
- After installing Resharper (org mandate) I'm seeing a lot of slowdown and messages like "blah seconds unresponsive because of Resharper". Also seeing general Windows lagginess in comparison to pre-install. Is this solved through configuring Resharper more completely or just throwing more horsepower at it? I currently have a 2 Core i5 @ 2.6GHz and 12gb RAM, using VS 2017.
- I really like SourceTree for git management, but is it really necessary any more? The impression I get is everyone just does stuff in VS proper now. I would only be mostly pulling and doing little commits here and there, not really anything complex.

Sorry if those are dumbo questions, looking forward to getting back into "real" development!

# ? Dec 7, 2018 19:26

mystes: May 31, 2006

I don't think the query syntax for linq was officially deprecated; it's just not very popular now.

# ? Dec 7, 2018 20:08

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Scaramouche posted:

- I'm seeing a lot of LINQ SQL type stuff, I had thought this was being deprecated? Or was it just folded into a more core library?

Let's unpack that statement a bit.

- There is SQL-like syntax for LINQ, called query syntax. That's not going anywhere, it's just syntactic sugar around LINQ queries.

- There was LINQ to SQL. LINQ to SQL is dead. It was an ORM that provided LINQ extension methods for SQL. Don't use LINQ to SQL.

- LINQ to SQL was replaced with Entity Framework / LINQ to Entities. It's not going anywhere. EF is pretty decent.

The syntax for LINQ vs LINQ to SQL vs LINQ to Entities is all going to be the same, because it's all just LINQ extension methods implemented for different data providers.

# ? Dec 7, 2018 20:31

EssOEss: Oct 23, 2006; 128-bit approved

And yes, I hear everyone complain about ReShaper slowness. You may be forced to have it installed but are you forced to have it enabled?

Personally, I have not felt any need for ReSharper in a long time. The only feature I might still miss if I did a lot of Windows GUI was its awesome template editor. For all those DependencyProperties that require 35 lines of boilerplate.

# ? Dec 7, 2018 22:47

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

EssOEss posted:

And yes, I hear everyone complain about ReShaper slowness. You may be forced to have it installed but are you forced to have it enabled? Personally, I have not felt any need for ReSharper in a long time. The only feature I might still miss if I did a lot of Windows GUI was its awesome template editor. For all those DependencyProperties that require 35 lines of boilerplate.

VS capabilities taking advantage of Roslyn have made ReSharper more or less obsolete. JetBrains didn't help things by doubling down on having their own internal parsing engine, so installing ReSharper is basically telling Visual Studio to do double the work.

# ? Dec 7, 2018 23:50

downout: Jul 6, 2009

Scaramouche posted:

Just giving all of you soon-to-be-my-best-friends a heads up, I'm moving back into the .NET world after being out of it for years. I'm going from WPF VB.NET circa 2010 into all new and cool C# MVVM/EF, so I'm sure I'll have tonnes of dumb questions as I get further into the details. I had some initial questions:
- I'm seeing a lot of LINQ SQL type stuff, I had thought this was being deprecated? Or was it just folded into a more core library?
- After installing Resharper (org mandate) I'm seeing a lot of slowdown and messages like "blah seconds unresponsive because of Resharper". Also seeing general Windows lagginess in comparison to pre-install. Is this solved through configuring Resharper more completely or just throwing more horsepower at it? I currently have a 2 Core i5 @ 2.6GHz and 12gb RAM, using VS 2017.
- I really like SourceTree for git management, but is it really necessary any more? The impression I get is everyone just does stuff in VS proper now. I would only be mostly pulling and doing little commits here and there, not really anything complex.

Sorry if those are dumbo questions, looking forward to getting back into "real" development!

I use sourcetree and VS together. VS for lots of commits, branch switching, and a few other things. Sourcetree for quick terminal in the right path, merging. But sourcetree is slow as hell and many other complaints.

# ? Dec 8, 2018 01:09

Cuntpunch: Oct 3, 2003; A monkey in a long line of kings

New Yorp New Yorp posted:

VS capabilities taking advantage of Roslyn have made ReSharper more or less obsolete. JetBrains didn't help things by doubling down on having their own internal parsing engine, so installing ReSharper is basically telling Visual Studio to do double the work.

I mean, only when put side-by-side against its closest competitor do you start to see that there wasn't necessarily a right answer. CodeRush(For Roslyn) tossed everything out and bought-in on Roslyn for the performance and tighter integration experience - but it's taken them years of development to bring the new version up to feature-parity with the old one. Time that JetBrains seems to have spent instead with the strategy of making their own IDE that is tightly integrated with ReSharper.

That said, ReSharper in 2018 is still a mess as a VS Extension. The amount of slowdown and resource consumption for a large-ish project is completely unacceptable.

# ? Dec 8, 2018 08:21

Ensign Expendable: Nov 11, 2008; Lager beer is proof that god loves us; Pillbug

EssOEss posted:

And yes, I hear everyone complain about ReShaper slowness. You may be forced to have it installed but are you forced to have it enabled? Personally, I have not felt any need for ReSharper in a long time. The only feature I might still miss if I did a lot of Windows GUI was its awesome template editor. For all those DependencyProperties that require 35 lines of boilerplate.

I installed resharper and it destroyed all of my keyboard shortcuts. No matter how many times I selected "use Visual Studio key bindings" it wouldn't bring them back.

# ? Dec 8, 2018 20:19

rarbatrol: Apr 17, 2011; Hurt//maim//kill.

Cuntpunch posted:

I mean, only when put side-by-side against its closest competitor do you start to see that there wasn't necessarily a right answer. CodeRush(For Roslyn) tossed everything out and bought-in on Roslyn for the performance and tighter integration experience - but it's taken them years of development to bring the new version up to feature-parity with the old one. Time that JetBrains seems to have spent instead with the strategy of making their own IDE that is tightly integrated with ReSharper.

That said, ReSharper in 2018 is still a mess as a VS Extension. The amount of slowdown and resource consumption for a large-ish project is completely unacceptable.

At my job, we have an "everything and the kitchen sink" solution in one of the repositories, with something like 600 projects in it. Resharper with VS 2015 is simply not an option with that.

# ? Dec 9, 2018 02:29

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Has anybody used Hangfire for background tasks? I saw it mentioned in a HN commenti and it looks pretty good, would save us a good chunk of boring code.

# ? Dec 9, 2018 17:10

Potassium Problems: Sep 28, 2001

NihilCredo posted:

Has anybody used Hangfire for background tasks? I saw it mentioned in a HN commenti and it looks pretty good, would save us a good chunk of boring code.

Yep, been using it for a few years to run early morning tasks (update this, email that, etc) and it's worked like a charm.

# ? Dec 9, 2018 17:45

mystes: May 31, 2006

That looks really nice. I've been looking for a simple cron replacement with a web interface but it seemed like anything that had a web interface was a ridiculously complicated distributed system with 500 dependencies.

# ? Dec 9, 2018 18:19

EssOEss: Oct 23, 2006; 128-bit approved

I used it. You can't really "fire and forget" it - you need to properly architect it into a solution. Another team did not bother and hosed up their job design so that they are limited to 1 concurrent job.

It is no magic bullet. It needs configuration, architecture and usage guidelines. If all you need is a for loop over Task<T>, do not get overly fancy.

# ? Dec 9, 2018 18:32

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

EssOEss posted:

I used it. You can't really "fire and forget" it - you need to properly architect it into a solution. Another team did not bother and hosed up their job design so that they are limited to 1 concurrent job.

It is no magic bullet. It needs configuration, architecture and usage guidelines. If all you need is a for loop over Task<T>, do not get overly fancy.

Interesting. Can you share an example of a mistake you can make by not integrating Hangfire in the correct way?

# ? Dec 9, 2018 20:25

EssOEss: Oct 23, 2006; 128-bit approved

It was some time ago that I looked into this, so I am sure I forget half of it but some things that came up when I was called in to help:

* Hangfire worker threads are normal priority by default, which means they compete with ASP.NET request processing threads. Lots of background jobs will prevent ASP.NET request processing as a consequence.
* Hangfire is not at all performant when storing large numbers of small jobs in a job queue in SQL database (as in, tens of thousands). My hypothesis was that this slowdown was caused by Hangfire not using COMB GUIDs for the row IDs and thereby causing massive index fragmentation on inserting randomly generated GUID primary keys. There may have been other contributing factors, as well - it was really crazy slow to deal with lots of small jobs.

Reading through my emails, I do not actually see it written why the team found themselves limited to one concurrent job execution. I vaguely remember it being something related to object graph lifetimes.

For sure, if I were to use Hangfire, I would only use it in ASP.NET to queue jobs but still excetute them in external services, away from the ASP.NET process. This ensures that most problems will only affect the jobs themselves, not the web service.

EssOEss fucked around with this message at 07:33 on Dec 10, 2018

# ? Dec 10, 2018 07:31

Xik: Mar 10, 2011; Dinosaur Gum

If you want "background" processes for your ASP.NET stuff rather than cron-like behavior .NET Core 2.1 has IHostedServices, which let you run code at configurable intervals outside the lifetime of a request.

# ? Dec 10, 2018 09:36

amotea: Mar 23, 2008; Grimey Drawer

https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUIAreGoingOpenSource.aspx

quote:

Buckle up friends! Microsoft is open sourcing WPF, Windows Forms (winforms), and WinUI, so the three major Windows UX technologies are going open source! All this is happening on the same day as .NET Core 3.0 Preview 1 is announced. Madness!

# ? Dec 10, 2018 22:33

Mr Shiny Pants: Nov 12, 2012

amotea posted:

https://www.hanselman.com/blog/AnnouncingWPFWinFormsAndWinUIAreGoingOpenSource.aspx

The cynic in me says they just want to get rid of it. "Here people, maybe you can make it work."

# ? Dec 11, 2018 12:24

Polio Vax Scene: Apr 5, 2009

Is there any functional difference between these two?:

var x = DoThingAsync().Result;

var y = DoThingAsync();
y.Wait();
var x = y.Result;

I understand that both go against the whole point of the async methodology, this is just for a POC console app.

# ? Dec 11, 2018 17:35

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Polio Vax Scene posted:

Is there any functional difference between these two?:

var x = DoThingAsync().Result;

var y = DoThingAsync();
y.Wait();
var x = y.Result;

I understand that both go against the whole point of the async methodology, this is just for a POC console app.

You don't need to call .Wait() when calling .Result, it happens implicitly.

# ? Dec 11, 2018 17:44

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

Polio Vax Scene posted:

Is there any functional difference between these two?:

var x = DoThingAsync().Result;

var y = DoThingAsync();
y.Wait();
var x = y.Result;

I understand that both go against the whole point of the async methodology, this is just for a POC console app.

Practically no, functionally kind of. Run it in SharpLab or something that lets you view IL and you'll see that it's practically the same except that you'll have some additional allocations for the wait and so forth.

# ? Dec 11, 2018 17:50

Che Delilas: Nov 23, 2009; FREE TIBET WEED

BUT BE CAREFUL ITS GOING TO DEADoh it's a console app carry on.

# ? Dec 11, 2018 19:23

redleader: Aug 18, 2005; Engage according to operational parameters

Che Delilas posted:

BUT BE CAREFUL ITS GOING TO DEADoh it's a console app carry on.

I hear this all the time, but some devs here have written ASP.NET code that uses Wait() and Result, and I've never seen or heard of a deadlock occurring.

Of course, that's probably due to our lacklustre monitoring and/or luck. Do IIS or ASP.NET kill deadlocked threads after they hit the request timeout? What symptoms would you expect if you were encountering deadlocks in that sort of environment?

# ? Dec 11, 2018 19:50

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

redleader posted:

I hear this all the time, but some devs here have written ASP.NET code that uses Wait() and Result, and I've never seen or heard of a deadlock occurring.

Of course, that's probably due to our lacklustre monitoring and/or luck. Do IIS or ASP.NET kill deadlocked threads after they hit the request timeout? What symptoms would you expect if you were encountering deadlocks in that sort of environment?

If you were seeing deadlocks, users would get long delays followed by errors when IIS eventually times out the request.

In my experience, it's way more of a problem when there's a UI thread involved.

# ? Dec 11, 2018 20:49

ljw1004: Jan 18, 2005; rum

redleader posted:

I hear this all the time, but some devs here have written ASP.NET code that uses Wait() and Result, and I've never seen or heard of a deadlock occurring.

https://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html

Legacy ASP.NET had a serializing synchronization context. Therefore, code like this would deadlock:

code:

tcs = new TaskCompletionSource<int>();

const fooTask = fooAsync();
blocking();
await fooTask;

async Task fooAsync() {
  await Task.Delay(10);
  tcs.SetResult(1);
}

int blocking() {
  return tcs.Task.Result;
}

What makes this deadlock is that the single flow of control gets blocked while waiting for Result, and because it's blocked, there's therefore no one available to resume after the await in "fooAsync".

Folks writing UI code ran into these deadlocks all the time. They're particularly gnarly because you can't look at any method in isolation to figure out what the bug is. You can only understand the bug by understanding the entire flow of control of the program. And that's why devs adopted the idiom of "never blocking in an otherwise async program".

Since ASP.NET Core got rid of its serializing execution context, there will always be someone available to resume after the await in fooAsync, and therefore this class of deadlocks won't happen.

# ? Dec 11, 2018 21:40

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

redleader posted:

I hear this all the time, but some devs here have written ASP.NET code that uses Wait() and Result, and I've never seen or heard of a deadlock occurring.

Of course, that's probably due to our lacklustre monitoring and/or luck. Do IIS or ASP.NET kill deadlocked threads after they hit the request timeout? What symptoms would you expect if you were encountering deadlocks in that sort of environment?

usually it will be caught by request timeout and cleaned up. in fiddler you'll see requests just stay open for a solid minute.

wait() and result is just asking for trouble, it might work if you're the only one using your server. i used to think it didn't matter until i burned a week trying to figure out why my code was causing an intermittent deadlock under load, it was awful, either do everything sync or everything async.

# ? Dec 11, 2018 21:52

redleader: Aug 18, 2005; Engage according to operational parameters

Thanks all. And yeah, ASP.NET legacy - should have clarified.

Sweet, so it sounds like the reason we haven't run into any visible problems is (1) luck and (2) terrible monitoring.

# ? Dec 12, 2018 00:18

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Thanks for the replies guys, especially the clarity on LINQ syntax versus LINQ to SQL.

I've also ended up disabling Resharper for now until I actually need it since it was causing two minute startup time delays, and sometimes Explorer would just up and crash. Now I just need to figure out all this Entity Framework stuff, which seems to be buried pretty deep.

# ? Dec 12, 2018 00:24

epswing: Nov 4, 2003; Soiled Meat

Has anyone recently built an Android/iOS app with Xamarin Forms and VS 2017? How was your experience? There are lots of "how to get started" videos on youtube, but I'm more looking for how it feels after the first hour. Is the app submission process reasonable? I'm not aiming to build anything revolutionary, mostly a LOB that talks to a backend service.

# ? Dec 12, 2018 03:15

beuges: Jul 4, 2005; fluffy bunny butterfly broomstick

epalm posted:

Has anyone recently built an Android/iOS app with Xamarin Forms and VS 2017? How was your experience? There are lots of "how to get started" videos on youtube, but I'm more looking for how it feels after the first hour. Is the app submission process reasonable? I'm not aiming to build anything revolutionary, mostly a LOB that talks to a backend service.

I've been doing a fair amount of Xamarin Forms dev in the past couple of months. It's not much different to getting used to a new framework. One thing that I still haven't gotten around to doing yet is working out how XAML works properly, so I just do all my layouts in code rather than XAML, which is not at all as tedious as it sounds, and I'm really not seeing myself missing out much. I had to jump into the deep end and do a couple of POC apps very quickly, so I need to go back to basics over the holidays and read/watch some tutorials to learn how to properly do all the stuff that I had to just make work, e.g. I just started using bindings a couple of weeks ago and I'm kicking myself for not having used them from the start.

# ? Dec 12, 2018 16:05

epswing: Nov 4, 2003; Soiled Meat

I have a few years of WPF experience so applying that to mobile sounds really attractive.

I just don�t want to get knee deep into Xamarin development only to discover it �kinda sorta mostly works some of the time� and is more an experiment than anything else.

# ? Dec 12, 2018 17:10

spaced ninja: Apr 10, 2009; Toilet Rascal

I've been doing Xamarin development for about two years now. Mostly Xamarin.iOS directly, a few smaller projects with Forms. Forms has made tons of progress over the last year in terms of functionality and is a really great platform. The biggest learning curve was mostly refreshing XAML knowledge since the last time I used it was for silverlight (the new XAML previewer makes this a lot easier as well). There are some limitations in forms due to the cross platform nature but almost everything is customizable via custom renderers, providing you understand the targeted platform (iOS/Droid etc) a bit.

# ? Dec 12, 2018 17:25

epswing: Nov 4, 2003; Soiled Meat

Ok, that�s what I was hoping for. Does VS 2017 Enterprise bring actually useful features to Xamarin development or is VS 2017 Professional sufficient? (E.g. I think I read that xaml previewer is an Enterprise feature.)

# ? Dec 12, 2018 18:53

spaced ninja: Apr 10, 2009; Toilet Rascal

epalm posted:

Ok, that�s what I was hoping for. Does VS 2017 Enterprise bring actually useful features to Xamarin development or is VS 2017 Professional sufficient? (E.g. I think I read that xaml previewer is an Enterprise feature.)

I believe the only things enterprise brings to the table these days is Xamarin Profiler and the Inspector (kinda like web tools in chrome). Both of which are fairly meh imo. I mostly use VS Enterprise for Mac these days so I can't really say how they work on windows. If you don't have enterprise you can still do profiling with the native tools as well (Instruments on Mac, not sure what android uses these days).

EDIT: I feel I should point out as well that if you plan on doing iOS development from a windows machine you will still need a Mac to actually do the builds.

spaced ninja fucked around with this message at 19:33 on Dec 12, 2018

# ? Dec 12, 2018 19:31

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I'm digging into Entity Framework, and I apologize for the basic nature of this question, but it feels like stuff is happening "invisibly" to me when a database update is committed. However I can't find the final statement that actually does the update/insert/etc. I believe this is because how Entity Framework operates, that is it is tightly bound to the database structure and once you reach a certain point (e.g. object.update(parameters)) syntactical sugar takes over and just does the database work, instead of calling stored procs and prepared strings like I'm used to.

The way I would learn a code base is find something I'm interested in and then keep diving through "Go To Definition/Implementation" until I get to the "nitty gritty" of whatever that call does. But in following these down I only end up at boilerplate definitions from metadata that are things like "public void InsertAllOnSubmit<TSubEntity>(IEnumerable<TSubEntity> entities) where TSubEntity : TEntity;". I get what's going on, but it feels weird not to see that final SQL statement.

There isn't really a question, just more of a musing that I'm used to seeing that almost "bare metal" view and by definition EF stuff as an ORM doesn't do that.

On the plus side, I'm sitting in on the scrum meetings and have learned what Floccinaucinihilipilification means.

# ? Dec 12, 2018 19:46

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

Scaramouche posted:

I'm digging into Entity Framework, and I apologize for the basic nature of this question, but it feels like stuff is happening "invisibly" to me when a database update is committed. However I can't find the final statement that actually does the update/insert/etc.

If you just want the SQL text, the queries should appear in 'info' blocks in the console when your command fires.

code:

info: Microsoft.EntityFrameworkCore.Infrastructure[10403]
      Entity Framework Core 2.1.4-rtm-31024 initialized 'FoobarContext' using provider 'Microsoft.EntityFrameworkCore.SqlServer' with options: None
info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (52ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
      SELECT [n].[Name]
      FROM [PeePeePooPoo] AS [n]
      ORDER BY [n].[Id]

If you want that EF to return the actual string to you in your program, there are ways to do logging that can get that. And you can issue Raw SQL on a DBContext if you don't want to use Linq.

# ? Dec 12, 2018 20:06

User0015: Nov 24, 2007; Please don't talk about your sexuality unless it serves the ~narrative~!

Scaramouche posted:

I'm digging into Entity Framework, and I apologize for the basic nature of this question, but it feels like stuff is happening "invisibly" to me when a database update is committed. However I can't find the final statement that actually does the update/insert/etc. I believe this is because how Entity Framework operates, that is it is tightly bound to the database structure and once you reach a certain point (e.g. object.update(parameters)) syntactical sugar takes over and just does the database work, instead of calling stored procs and prepared strings like I'm used to.

The way I would learn a code base is find something I'm interested in and then keep diving through "Go To Definition/Implementation" until I get to the "nitty gritty" of whatever that call does. But in following these down I only end up at boilerplate definitions from metadata that are things like "public void InsertAllOnSubmit<TSubEntity>(IEnumerable<TSubEntity> entities) where TSubEntity : TEntity;". I get what's going on, but it feels weird not to see that final SQL statement.

There isn't really a question, just more of a musing that I'm used to seeing that almost "bare metal" view and by definition EF stuff as an ORM doesn't do that.

On the plus side, I'm sitting in on the scrum meetings and have learned what Floccinaucinihilipilification means.

You can request the SQL script that EF will run as part of the update process. I don't know if that helps you at all. I'm brand new to EF as well, and it's a quirky little thing.

# ? Dec 13, 2018 17:43

Captain Capacitor: Jan 21, 2008; The code you say?

spaced ninja posted:

EDIT: I feel I should point out as well that if you plan on doing iOS development from a windows machine you will still need a Mac to actually do the builds.

For testing, sure. Not so much for CI/CD anymore.

# ? Dec 13, 2018 21:35

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 02:55

Xik: Mar 10, 2011; Dinosaur Gum

Captain Capacitor posted:

For testing, sure. Not so much for CI/CD anymore.

You still need somewhere to host the agent. So if you don't have your own Mac to host it you need to shell out monthly for one of the mac cloud providers. Last I investigated they were pretty limited and weren't particularly cheap (admittedly it's been a couple years since I checked), it ended up being worth it to just have a mac mini hanging around for builds and testing.

# ? Dec 16, 2018 00:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > .NET Megathread 3.5: await GetGoodPosts()

«‹›299 »