|
Malcolm XML posted:install http client libraries from nuget and use those https://www.nuget.org/packages/Microsoft.Net.Http It's unclear to me how grabbing something else in an extra complicated way is going to make that new thing available on a remote computer I have zero control over and is already missing core functionality? Am I missing some bit about how this works?
|
#
?
Feb 5, 2015 02:11
|
|
|
|
| # ? May 15, 2024 19:19 |
|
|
JawnV6 posted:It's unclear to me how grabbing something else in an extra complicated way is going to make that new thing available on a remote computer I have zero control over and is already missing core functionality? Am I missing some bit about how this works? how are you deploying code to a server you have no control over? and who pissed in your cornflakes? nuget is standard for component delivery on .NET. clearly the application is linked against HWR or you'd fail at binding time as opposed to run time so fix your broken deployment by either sidestepping HWR or not using mono
|
|
#
?
Feb 5, 2015 02:18
|
|
|
I'm not using mono. The only error pages that popped up are in reference to mono. I'm clearly not explaining myself all that well, and I apologize for the tone. I don't want to explain the horrible delivery I'm papering over with "deployed" nor the environment this is running in so it's just X/Ying from here down. I've tried rewriting it with WebClient instead of HWR, that's probably going to suffice for this round of onion peeling. Cheers!
|
|
#
?
Feb 5, 2015 02:22
|
|
|
JawnV6 posted:It's unclear to me how grabbing something else in an extra complicated way is going to make that new thing available on a remote computer I have zero control over and is already missing core functionality? Am I missing some bit about how this works? I don't understand the error report quote:Method not found: 'System.Net.HttpWebRequest' One possibility is that there's a mismatch between the reference-assemblies that you compiled against and the actual assemblies on the target machine. Using the NuGet package Microsoft.Net.HttpClient would perhaps solve that because at least HttpClient would be packaged app-locally if needed, and you'd rely on the MS folks who wrote it to do the right binding on the target machine. I know that others of the MS NuGet packages do dynamic checks based on what runtime assemblies they actually load. (Also, HttpClient has a nicer API than WebRequest). Another possibility, reading between the tea-leaves, is that you're making an entirely valid HttpRequest, and this is going to an ASP.NET server, and that server itself is returning some kind of error code, and you're properly surfacing that error. I don't know. You're imaging the possibility that System.Net.dll is absent on the target machine, and that Microsoft.Net.HttpClient is a wrapper built around it. That's possible but seems unlikely because -- why would it be absent??
|
|
#
?
Feb 5, 2015 02:24
|
|
|
ljw1004 posted:You're imaging the possibility that System.Net.dll is absent on the target machine, and that Microsoft.Net.HttpClient is a wrapper built around it. That's possible but seems unlikely because -- why would it be absent?? I'm looking at a screenshot from a factory floor. They might not have the latest/greatest setup there, but they have enough .NET to put a button on the screen so it hasn't been an issue so far. I didn't close the single quote because the dialog didn't close the quote. I understand that the actual method isn't present in what I'm saying, that information is unavailable to me as well. I posted the entirety of the code, thinking that the single method call on that object would be enough information.
|
|
#
?
Feb 5, 2015 02:30
|
|
|
This is pretty off the wall, but does anyone know if there's a keyboard shortcut in VS to move the location of a document tab? For example, let's say I have 10 files open and I'm looking at the 7th one. If I want to move the location of that tab, right now I have to grab my mouse and move the location manually. I'm looking to be able to use the keyboard to move it either backward or forward, or maybe just to the first position. In Firefox, you can do this with Ctrl+Shift+PgUp/PgDown.
|
|
#
?
Feb 5, 2015 16:47
|
|
|
Bognar posted:This is pretty off the wall, but does anyone know if there's a keyboard shortcut in VS to move the location of a document tab? For example, let's say I have 10 files open and I'm looking at the 7th one. If I want to move the location of that tab, right now I have to grab my mouse and move the location manually. I'm looking to be able to use the keyboard to move it either backward or forward, or maybe just to the first position. If you've got multiple panels open you could do Alt + -, x (or r) then do it again in the reverse direction. That will land your panel on top of the stack that it started in. Bit of a mouthful though. e: (Or do alt + -, v in order to pop it into a new group. Then popping it back to previous will kill the new group.) e2: Playing with this now and it's not actually that bad. Hold Alt throughout, press -v-r, and the panel has moved to the top in its window. Newf fucked around with this message at 17:54 on Feb 5, 2015 |
|
#
?
Feb 5, 2015 17:50
|
|
|
Neat, that's a pretty creative way of pulling that off. It lags a bit when opening a new panel, so the last R keypress doesn't necessarily get registered. I'll just have to slow down when I want to do that. Thanks!
|
|
#
?
Feb 5, 2015 22:46
|
|
|
Big git merges invariably break csproj files and it sucks. Do you guys have any strategies to deal with that?
|
|
#
?
Feb 6, 2015 05:00
|
|
|
RICHUNCLEPENNYBAGS posted:Big git merges invariably break csproj files and it sucks. Do you guys have any strategies to deal with that? I do that all the time but with TFS. Is it somehow fundamentally different in git? My strategy is to do it very, very carefully, and merge as often as I can so the .csproj files don't diverge very much. I also yell at people not to refactor and move a bunch of files around in certain branches so the eventual merge doesn't become a mess. If the branches are planned well there aren't too many conflicts. Merging a 10,000 line .sln file is also fun 
|
|
#
?
Feb 6, 2015 05:16
|
|
|
Cryolite posted:I do that all the time but with TFS. Is it somehow fundamentally different in git? Probably not; the problem is that the merge doesn't know about XML so it sees the same closing tag in two different documents and makes an invalid XML file.
|
|
#
?
Feb 6, 2015 14:10
|
|
|
Does anyone have any experience with Entity Framework in a load balancing environment? And if so, what sort of pitfalls should I be looking out for with regard to db locking / results caching?
|
|
#
?
Feb 7, 2015 04:01
|
|
|
aBagorn posted:Does anyone have any experience with Entity Framework in a load balancing environment? Caching is a pain in the rear end with EF because the entities are attached to contexts. Cache values, not entities.
|
|
#
?
Feb 8, 2015 05:27
|
|
|
RICHUNCLEPENNYBAGS posted:Big git merges invariably break csproj files and it sucks. Do you guys have any strategies to deal with that? The trick to avoiding big, painful merges is to not have big merges. Stuff like rebasing the feature branches off of master is a good place to start. That said, I've done a fair bit of merging of things and I've never had that much trouble with the project files -- the modern iterations are pretty clean and most changes are not that troublesome. What git client are you using to do the merges?
|
|
#
?
Feb 9, 2015 21:03
|
|
|
wwb posted:The trick to avoiding big, painful merges is to not have big merges. Stuff like rebasing the feature branches off of master is a good place to start. I just do it from the command line. I have a merge tool but the thing is most of the merges are successful; they just result in invalid XML.
|
|
#
?
Feb 9, 2015 21:55
|
|
|
I can't think of a time where I had a non-conflicting git merge break a .csproj file.
|
|
#
?
Feb 9, 2015 22:04
|
|
|
Architect says hundreds of sprocs are less maintainable than EF. I don't know if that's true, but having heard about SSDT I wonder how easy that's gotten lately. Also, we use git, not TFS - is this a problem? I can always fiddle with SSDT on my own but I'm just an upstart build guy, not. A DBA or admin. What should I try to show with it?
|
|
#
?
Feb 9, 2015 23:08
|
|
|
Space Whale posted:Architect says hundreds of sprocs are less maintainable than EF. Stored procedures encourage you to cram business logic in your data access layer, which is never a good thing. I'd tend to agree with your architect, even taking SSDT into account. Have you ever renamed a column used in several dozen stored procedures? It can be a big pain in the rear end. SSDT doesn't care what you use for source control, it just represents your database schema in a source control-friendly fashion.
|
|
#
?
Feb 9, 2015 23:46
|
|
|
Bognar posted:I can't think of a time where I had a non-conflicting git merge break a .csproj file. Me too. I'd try using a better merge tool -- I have had some success with sourcetree. I also really like kdiff2 which comes bundled with tortoisehg.
|
|
#
?
Feb 9, 2015 23:57
|
|
|
Ithaqua posted:Stored procedures encourage you to cram business logic in your data access layer, which is never a good thing. I'd tend to agree with your architect, even taking SSDT into account. Have you ever renamed a column used in several dozen stored procedures? It can be a big pain in the rear end. The client's DBA I'm working with is the opposite. He wants everything done with stored procs, and I'm trying to convince him to let us use EF, hence my above question. He said something at our last meeting about EF caching and locking data in a load balanced environment, and that it scales horribly because of that, but prefaced that he last worked with EF 4. I can't find any definitive definitions either way about EF6. If my application is being used by 2+ servers simultaneously to hit the same database, how is EF6 going to handle concurrency? Should I be disposing context every chance I get to avoid race conditions?
|
|
#
?
Feb 10, 2015 00:43
|
|
|
My business is also one that does 80% of things in stored procs for our main product. We also support both MSSQL and Oracle. I'd rather gouge my eyeballs out than jump into that mess. Instead I'm navigating towards the mobile world with Xamarin for iOS and Android. Can anyone tell me how fun that is going to be?
|
|
#
?
Feb 10, 2015 00:56
|
|
|
aBagorn posted:If my application is being used by 2+ servers simultaneously to hit the same database, how is EF6 going to handle concurrency? Should I be disposing context every chance I get to avoid race conditions? Disposing contexts has nothing to do with race conditions or concurrency. In fact, it's not (strictly speaking) necessary: http://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext.html#.U6WdzrGEeTw Dealing with concurrent data data access/updates in EF6: http://www.asp.net/mvc/overview/get...mvc-application Transactions in EF6: https://msdn.microsoft.com/en-us/data/dn456843.aspx
|
|
#
?
Feb 10, 2015 01:04
|
|
|
^^^^^^Listen to Ithaqua over me, I guess I'm wrong, however I'll leave what I've experienced here.aBagorn posted:Should I be disposing context every chance I get to avoid race conditions? I can't speak on caching/load balancing, but yes, you should dispose context every time you use it. Always wrap it in a using statement. I gather that it's meant to be thrown away and use a new one every time. If you don't, you'll get weird poo poo happening and it won't always manifest itself right away, making the problem that much less obvious. I also had some really, really bad performance issue's that were solved when I stopped trying to reuse a context. VVVV Hah, well yeah that's what I meant.
Essential fucked around with this message at 01:14 on Feb 10, 2015 |
|
#
?
Feb 10, 2015 01:07
|
|
|
Essential posted:^^^^^^Listen to Ithaqua over me, I guess I'm wrong, however I'll leave what I've experienced here. Listen to the guy who wrote that blog post, not me. He actually spoke to people who work on EF. I don't know poo poo. 
|
|
#
?
Feb 10, 2015 01:11
|
|
|
Follow up, so if I'm reading these correctly, EF does NOT by default lock DB rows? This is something that he's hung up on and the more ammo I can take in the better.
|
|
#
?
Feb 10, 2015 02:28
|
|
|
Anyone have any good resources on how to use nRefactory? Aside from the Codeproject site?
|
|
#
?
Feb 10, 2015 02:43
|
|
|
aBagorn posted:Follow up, so if I'm reading these correctly, EF does NOT by default lock DB rows? What migration strategy will you be using, and how does the DBA feel about that? edit: that's a context per web request, not DB request.
|
|
#
?
Feb 10, 2015 03:13
|
|
|
aBagorn posted:Follow up, so if I'm reading these correctly, EF does NOT by default lock DB rows? EF will not be doing anything special when calling your database compared to any other way of talking to your database. It should be using a read committed database isolation level by default, and you can explicitly change this in cases if you want to. When performing updates, individual commands will be sent for each row updated. Row locks will occur in the same fashion as if you have manually pushed out the same commands. Some differences in a load balanced scenario that I can think of (which are fairly minor): - EF has a once-off slow startup time (validating its model is correct) which will occur on each server. - When you write a query with linq, EF needs to generate the necessary parameterized sql query. This can take a relatively long time, so after it has been called, EF caches this, so that next time it will already have the generated sql and run really fast. This cost also will need to occur on each server.
|
|
#
?
Feb 10, 2015 04:08
|
|
|
wwb posted:Me too. Why would that make a difference if there are no conflicts? It just ends up assuming closing tags and so on are duplicated between versions when it isn't necessarily true.
|
|
#
?
Feb 10, 2015 15:11
|
|
|
aBagorn posted:Follow up, so if I'm reading these correctly, EF does NOT by default lock DB rows? This guy sounds like he's off his rocker. There's nothing different about running EF distributed or not, and definitely not in regards to DB locking. EF makes no explicit choice to lock tables or rows (though SQL Server may choose to do so depending on the query - EF or not). If he still takes convincing, just hook up a profiler. There's nothing terribly special about the SQL that EF generates, aside from the fact that it can be horribly verbose at times.
|
|
#
?
Feb 10, 2015 15:25
|
|
|
Just so I know and I don't start looking for faeries and pixies in my computer: How the gently caress can something build on my machine, even if the reference to a dependency is broken? It clearly won't do it on my build server, which is why I care, but when I look at my machine it's... not there either. Is it in the Global Assembly Cache? Just in the ether? wtf Also, in general, how much of a PITA is it to finally whip a solution into building properly and using NuGet correctly?
|
|
#
?
Feb 10, 2015 15:58
|
|
|
Space Whale posted:... a PITA ... whip a solution ... using NuGet... Great, now I'm hungry. 
|
|
#
?
Feb 10, 2015 16:23
|
|
|
Space Whale posted:Just so I know and I don't start looking for faeries and pixies in my computer: How the gently caress can something build on my machine, even if the reference to a dependency is broken? It clearly won't do it on my build server, which is why I care, but when I look at my machine it's... not there either. I'd always check the GAC first in a situation like that. Of course, I've also been traumatized by SharePoint development where deploying a solution puts all of your dependencies in the GAC which leads to a bunch of loving problems on other projects. For example, if you have a library in the GAC, then the Azure deployment process from VS may not copy that library to the deployment target - leading to a week where we would only deploy from one machine because it magically worked there and not elsewhere and we couldn't figure out why.
|
|
#
?
Feb 10, 2015 16:27
|
|
|
Bognar posted:I'd always check the GAC first in a situation like that. Of course, I've also been traumatized by SharePoint development where deploying a solution puts all of your dependencies in the GAC which leads to a bunch of loving problems on other projects. For example, if you have a library in the GAC, then the Azure deployment process from VS may not copy that library to the deployment target - leading to a week where we would only deploy from one machine because it magically worked there and not elsewhere and we couldn't figure out why. Dealing with this now myself. I'm also looking for a new job.
|
|
#
?
Feb 10, 2015 16:56
|
|
|
RICHUNCLEPENNYBAGS posted:Why would that make a difference if there are no conflicts? I'm not sure but I suspect seeing what is going on will help -- it sounds like someone is doing something retarded like switching line endings which is blowing things up. Have you looked at a diff before you merged?
|
|
#
?
Feb 10, 2015 17:04
|
|
|
For what it's worth, I've seen non-conflicting merges produce invalid XML in project files as well.
|
|
#
?
Feb 10, 2015 17:08
|
|
|
Space Whale posted:Also, in general, how much of a PITA is it to finally whip a solution into building properly and using NuGet correctly? It's very easy. NuGet.org has docs that explain everything in excruciating detail.
|
|
#
?
Feb 10, 2015 17:35
|
|
|
Space Whale posted:Also, in general, how much of a PITA is it to finally whip a solution into building properly and using NuGet correctly? Not that bad. If you have Resharper if you right click on the reference and pick Project Hierarchy it will show you all of the projects referencing the assembly. You can then right click on the solution, manage Nuget packages for solution, and add the package to your projects. I recheck the references to make sure they are correct because I've had Nuget not do the right thing. If your build system doesn't restore nuget packages automatically you'll have to check nuget.org for instructions. For internal assemblies you can run your own nuget server if needed. I'm literally in the process of doing this at work for some of our external dependencies. Someone added a new project with log4net through Nuget, but other projects had references to the assembly in a lib folder. Everything compiled but programs crashed, very annoying.
|
|
#
?
Feb 10, 2015 18:13
|
|
|
RICHUNCLEPENNYBAGS posted:Big git merges invariably break csproj files and it sucks. Do you guys have any strategies to deal with that? Also, the default in-place merging puts all changes into the same file. While it allows you to use any text editor for the cleanup, IMHO it's easy to forget to delete duplicate lines or leave invalid XML in. I prefer to use Visual Studio's own three-way merge, where the two source files are kept separate from the merged file. You can tell Git to use Visual Studio for diffs and merges by adding the following lines to your .gitconfig: code:
|
|
#
?
Feb 10, 2015 19:17
|
|
|
|
| # ? May 15, 2024 19:19 |
|
|
Huh, I've never used Visual Studio's diff merge, I always just installed Tortoise Git to use their graphical merge tool which is pretty decent. Anyone have a comparison between the two?
|
|
#
?
Feb 10, 2015 19:29
|
|