|
LongSack posted:I could not, for the life of me, figure out how to use the dictionary’s existing GetEnumerator() to do so. The compiler kept complaining that it couldn’t convert from Dictionary<string,object>.IEnumerator to IEnumerator<Dictionary<string, object>>. Dictionary<string, object>.Enumerator is IEnumerator<KeyValuePair<string, object>>, not IEnumerator<Dictionary<string, object>>. It enumerates the contents of a single dictionary, whereas an IEnumerator<Dictionary<string, object>> enumerates multiple dictionaries.
|
#
?
Oct 12, 2018 01:40
|
|
|
|
| # ? Jun 1, 2024 21:34 |
|
|
I have an application which uses ASP MVC / Razor. I need to add a reference to a DLL we created. Our DLL references newer versions of System.Web.Mvc, System.Web.Razor, System.Web.WebPages, and System.Web.WebPages.Razor This caused a few issues; I forget the exact error but it was something to the effect of "Reference uses newer versions of other references this project already uses". All I had to do was delete a bunch of those System.Web.* references and re-add them so that it's using the same version as what our DLL uses. Now I can build and run the application locally. Great! So I push our DLL, all the System.Web.* DLLs I had to update in the project, and the DLL for this application itself to the web server. If I try to navigate to the site, I get this error: quote:[A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. I sort of understand what it's telling me; there's a version error in the DLLs used. But I don't understand why because I can run it locally. I pushed all the relevant DLLs to the server. It sounds like I just need to update the GAC with v3.0 of the DLL but frankly I (and my boss) am a little reluctant to find out what the repercussions of that might be? We have other, more important, products which also rely on all the MVC DLLs. Sab669 fucked around with this message at 14:17 on Oct 12, 2018 |
|
#
?
Oct 12, 2018 14:07
|
|
|
mystes posted:What do you mean when you say you want it to be "IEnumerator<Dictionary<string, object>>"? That would enumerate over dictionaries which doesn't make any sense. Night Shade posted:Dictionary<string, object>.Enumerator is IEnumerator<KeyValuePair<string, object>>, not IEnumerator<Dictionary<string, object>>. It enumerates the contents of a single dictionary, whereas an IEnumerator<Dictionary<string, object>> enumerates multiple dictionaries. Ahh ok that makes sense. Thanks!
|
|
#
?
Oct 12, 2018 17:41
|
|
|
Sab669 posted:I have an application which uses ASP MVC / Razor. I need to add a reference to a DLL we created. Our DLL references newer versions of System.Web.Mvc, System.Web.Razor, System.Web.WebPages, and System.Web.WebPages.Razor .Net core? You can add a local DLL and it will use that instead of the GAC one. Don't know if this also works on Windows, but on Linux you can use the following: https://github.com/dotnet/core/blob/master/Documentation/self-contained-linux-apps.md
|
|
#
?
Oct 12, 2018 18:22
|
|
|
Sab669 posted:"Reference uses newer versions of other references this project already uses". All I had to do was delete a bunch of those System.Web.* references and re-add them so that it's using the same version as what our DLL uses. This raises all sorts of questions about how exactly your dependency management is organized and whether it is sane. However, the fix with .NET Framework is pretty universal: define some assembly binding redirects. Basically, you just tell .NET Framework "whenever someone asks for XYZ.dll version 0.0.0.0-1.2.3.4 always use 1.2.3.4". Naturally, it only works if the assembly 1.2.3.4 is actually backward compatible but as long as it is a Microsoft assembly, you are pretty safe in assuming that. Why I wonder about your dependency management is that in many cases, the binding redirects get added automatically these days, at least if you are using latest Visual Studio. Granted, the Microsoft SDKs tend to be buggy as hell when dealing with assembly versioning and packaging, so I am not surprised to hear some things do not work out of the box. Try manually redirecting the assemblies you need.
|
|
#
?
Oct 12, 2018 20:15
|
|
|
EssOEss posted:However, the fix with .NET Framework is pretty universal: define some assembly binding redirects. Basically, you just tell .NET Framework "whenever someone asks for XYZ.dll version 0.0.0.0-1.2.3.4 always use 1.2.3.4". Also known as the Newtonsoft Json.NET workaround, since every package on earth has a dependency on some version of this rapidly iterated package.
|
|
#
?
Oct 12, 2018 21:34
|
|
|
Cross posting with the questions thread, as this is a squirrely .NET question.Magnetic North posted:So this is a bit of a weird one. I am using C# in Visual Studio 2015. Does anyone know how one could subscribe to an event listener that is a member of a dynamic object that was created through late binding? And/or how to create a method that has a parameter of a type that is only known to an assembly loaded late?
|
|
#
?
Oct 13, 2018 13:09
|
|
|
Is anyone else experiencing problems with the VS2017 C# debugger? It often won't let me inspect variables or properties of class instances, i.e. they just show up empty in the watch window or VS goes in an 'evaluating expression' loading loop or 'The debugger is unable to evaluate this expression'. These issues started like a year ago.
|
|
#
?
Oct 15, 2018 12:30
|
|
|
So I've started a front-end job with a company that uses MVC 5 and something called Episerver. I'm Angular dev, but we don't really do many SPA's because we're using MVC, and while no one has asked me to learn anything to do with .NET, I hate being completely ignorant about a part of the stack I'm working on so I'm doing a Udemy course on MVC 5, not even Core, and I just want to say I think MVC 5 owns, and C# owns, and one day I'll do a Core course as well just to do something more modern but still. It's dope and I love it and its cool and I just wanted to say that. You can also really see how MicroSoft were thinking when they created TypeScript because its clearly inspired, I think, by C#.
|
|
#
?
Oct 15, 2018 21:42
|
|
|
Has anyone used System.Speech.Synthesis.SpeechSynthesizer and if so have you noticed it getting louder if you pause and then resume?
|
|
#
?
Oct 15, 2018 21:49
|
|
|
Ape Fist posted:You can also really see how MicroSoft were thinking when they created TypeScript because its clearly inspired, I think, by C#. It's even made by the same person!
|
|
#
?
Oct 15, 2018 22:00
|
|
|
amotea posted:Is anyone else experiencing problems with the VS2017 C# debugger? It often won't let me inspect variables or properties of class instances, i.e. they just show up empty in the watch window or VS goes in an 'evaluating expression' loading loop or 'The debugger is unable to evaluate this expression'. I have this happen somewhat often when debugging Unity stuff. I had assumed it was related to using the Unity debugger, but haven't really done much non-Unity C# development recently, so it could be more widespread. I also pretty frequently run into the debugger UI just not refreshing until the window is resized. Restarting Visual Studio usually clears that one up.
|
|
#
?
Oct 15, 2018 22:13
|
|
|
amotea posted:Is anyone else experiencing problems with the VS2017 C# debugger? It often won't let me inspect variables or properties of class instances, i.e. they just show up empty in the watch window or VS goes in an 'evaluating expression' loading loop or 'The debugger is unable to evaluate this expression'. Ive recently switched to a project in vs2017, and ive had a similar experience. My mvc application causes the browser to think the application is unresponsive while the debugger churns through a minor variable. I was wondering if it was the project, but this makes it sound like a more general issue. Probably some random debugging option in vs needs disabled or something
|
|
#
?
Oct 16, 2018 00:32
|
|
|
Magnetic North posted:Cross posting with the questions thread, as this is a squirrely .NET question. Have you read https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/how-to-hook-up-a-delegate-using-reflection ? amotea posted:Is anyone else experiencing problems with the VS2017 C# debugger? It often won't let me inspect variables or properties of class instances, i.e. they just show up empty in the watch window or VS goes in an 'evaluating expression' loading loop or 'The debugger is unable to evaluate this expression'. This kind of thing happens to me when there's a lot of system memory pressure (as in getting near 150% of physical RAM) or if there's a DLL mismatch. If it's happening consistently, I'd guess it's the former unless you're doing a lot of Forms custom control development which IME tends to get a lot of DLLs stuck in the GAC, but I haven't done that since 2012 (year and VS version).
|
|
#
?
Oct 16, 2018 16:02
|
|
|
This is more of a VS question, rather than strictly .NET, but I’m hoping someone can help me with this. Working on a fancy replacement for MessageBox which is completely customizable, from the window icon, to the text in the buttons, whatever. But I want to provide some defaults. I am using pack URI’s to pull the images from the library assembly rather than the calling assembly. But it wasn’t working. Each button image and the main icon threw an exception, the root of which was an IOException saying the resource couldn’t be located. After struggling with it for way too long (I was close to abandoning the project), I did a clean and a build. And I got an error message from my test app build that said the library couldn’t be located. Aha! It’s building them in the wrong order. So I added a dependency in the test app to the library and rebuilt. Presto - everything worked. Suddenly with no other change the images loaded. I’m curious what’s the difference of merely adding the library to the test app’s references versus doing that and adding the dependency. Why did that make so much difference? In this case, both assemblies are in the same solution, rather than my normal usage of the library from a separate solution.
|
|
#
?
Oct 17, 2018 01:16
|
|
|
Ape Fist posted:So I've started a front-end job with a company that uses MVC 5 and something called Episerver. I remember my first C# experience after working entirely in PHP. Man did I enjoy C# then, and I still love it now. Also good work on making the frontend/backend jump! Too many people (backend AND frontend devs alike) refuse to touch code outside of their comfort zone.
|
|
#
?
Oct 17, 2018 10:07
|
|
|
The current problems I was having with the debugger were probably caused by this mess: https://github.com/dotnet/standard/issues/481 I have a .NET 4.6.1 unit test project that uses some fancy testing libraries that have a dependency on netstandard something something .NET Core 2 Netstandard 1.6 Desktop Targeting Pack PCL DNX and the thing crashes with a missing System.Runtime.dll dependency which I shouldn't need. The takeaway seems to be: only use the new Core/Netstandard stuff if you are on .NET 4.7.x.
|
|
#
?
Oct 17, 2018 10:08
|
|
|
At least 4.7.1 still has idiotic issues with Microsoft assemblies like System.Runtime not loading. Naturally, Microsoft closes the issue because you can hack around it by modifying your project file and using non-default settings or whatever the gently caress that is. I find hilarious the Rider developer who is also a BenchmarkDotNet developer saying "just use Rider". If Rider can unfuck Microsoft's dependency mess, it might actually have a case to make!
|
|
#
?
Oct 17, 2018 13:16
|
|
|
How often does upgrading .NET version actually break things in code? It feels to me like 95% of the problems you can run into are things like this where the tooling ends up linking the wrong assemblies. But that complicated tooling only seems to exist in the first place to try to make things backwards compatible with previous attempts to deal with DLL hell. I'm trying to think what would be the biggest problem if there was a hard cutoff with Standard 2.0 and Framework 4.7, and the main one I can come up with is projects that depend on abandoned libraries where the only NuGet packages available are targeting something older. But then people shouldn't be using abandoned libraries that aren't getting security updates so...
|
|
#
?
Oct 17, 2018 13:23
|
|
|
Yeah, overengineered dependency management is 90% of this hell. Microsoft really messed it up for a few years and we all have to suffer the fallout for a long time to come. I look back on the "drop a DLL file into the lib directory" days with yearning.
|
|
#
?
Oct 17, 2018 13:28
|
|
|
Scikar posted:How often does upgrading .NET version actually break things in code? It feels to me like 95% of the problems you can run into are things like this where the tooling ends up linking the wrong assemblies. But that complicated tooling only seems to exist in the first place to try to make things backwards compatible with previous attempts to deal with DLL hell. I'm trying to think what would be the biggest problem if there was a hard cutoff with Standard 2.0 and Framework 4.7, and the main one I can come up with is projects that depend on abandoned libraries where the only NuGet packages available are targeting something older. But then people shouldn't be using abandoned libraries that aren't getting security updates so... I agree, but at the same time I'm working with vendor libraries (non-.NET) that are 13+ years old. Another example: some customers were still running Windows XP only 2 years ago.
|
|
#
?
Oct 17, 2018 13:35
|
|
|
EssOEss posted:Yeah, overengineered dependency management is 90% of this hell. Microsoft really messed it up for a few years and we all have to suffer the fallout for a long time to come. It also seems NuGet is getting some secret magic fixes/workarounds for .NET eco-system issues now and then, while Paket sort of has to figure things out on its own. Kind of lovely, since Paket was the only viable way of managing dependencies for 1-2 years when NuGet was terrible.
|
|
#
?
Oct 17, 2018 13:39
|
|
|
Scikar posted:How often does upgrading .NET version actually break things in code? Almost never, but when it does, it sucks. It's usually your own fault (e.g. relying on implementation-specific behavior that's not guaranteed), or a well-documented breaking change that people ignore and then complain about. But there have been legit nasty bugs that have slipped by Microsoft.
|
|
#
?
Oct 17, 2018 13:57
|
|
|
LongSack posted:This is more of a VS question, rather than strictly .NET, but I’m hoping someone can help me with this. I don't understand the distinction you're making between a 'reference' and a 'dependency' here and maybe I'm not the only one?
|
|
#
?
Oct 17, 2018 14:37
|
|
|
Munkeymon posted:I don't understand the distinction you're making between a 'reference' and a 'dependency' here and maybe I'm not the only one? I think he's referring to a project reference vs a direct assembly reference.
|
|
#
?
Oct 17, 2018 15:02
|
|
|
New Yorp New Yorp posted:Almost never, but when it does, it sucks. It should not be this complicated in the first place, dependency hell in TYOOL 2018 is just stupid. Especially when it was better in the past. Which framework do you target? Do we have it installed? Great we'll use that. I have never from 2010 onward had as many stupid things that needed fixing by editing a csproj or an fsproj than in the last couple of years since the whole netstandard shitshow started happening.
|
|
#
?
Oct 17, 2018 16:58
|
|
|
Mr Shiny Pants posted:It should not be this complicated in the first place, dependency hell in TYOOL 2018 is just stupid. Especially when it was better in the past. Which framework do you target? Do we have it installed? Great we'll use that. No, I totally agree. They decided to replicate the worst part of the node ecosystem.
|
|
#
?
Oct 17, 2018 17:05
|
|
|
New Yorp New Yorp posted:No, I totally agree. They decided to replicate the worst part of the node ecosystem. Don't get me started on the "let's make System.Text a separate download, you guys like modules right?" Ugh.
|
|
#
?
Oct 17, 2018 17:11
|
|
|
amotea posted:I agree, but at the same time I'm working with vendor libraries (non-.NET) that are 13+ years old. (*) because IT keeps giving it digital CPR and hamstringing development in other areas to cater to the application. When Apple switched from PowerPC to x86 they included PPC emulation but clearly told everyone that it was a stopgap measure and would go away. Then they dropped PowerPC support like a hot potato and people just had to loving deal with it. They've also announced ending support for x86 soon. Microsoft at the very least needs to do the same for obsolete versions of NET.
|
|
#
?
Oct 17, 2018 17:53
|
|
|
"Hey Microsoft, you need to lose a bunch of enterprise business for my comfort!" "Why are you laughing? This is important!"
|
|
#
?
Oct 17, 2018 18:30
|
|
|
Yeah apple can drop support left and right because no one runs important software on it.
|
|
#
?
Oct 17, 2018 18:40
|
|
|
Apple is not the greatest example, but the way MS handled the whole netstandard/.net/net core stuff is pretty lousy.
|
|
#
?
Oct 17, 2018 18:55
|
|
|
Mr Shiny Pants posted:Don't get me started on the "let's make System.Text a separate download, you guys like modules right?" I may have news, I read this while crawling Github for bits and pieces: quote:With respect to the OP comment. Those DLLs are no longer distributed via nuget. NuGet dependencies for framework components/netstandard had too many issues. We've gone back to the "inbox" model where 4.7.1 has reabsorbed all these DLLs back into the framework. You'll find the reference dlls provided by the targeting pack, just like any other inbox dll. The implementations will available in the GAC. It is by design that we'll ignore the package versions and unify to the targeting-pack version. Those DLLs are no longer distributed via NuGet. I think this is about what you're referring to, but who knows.
|
|
#
?
Oct 17, 2018 21:18
|
|
|
Good, I think they had gone a bit overboard.
|
|
#
?
Oct 17, 2018 22:10
|
|
|
I don't think MS should immediately give up on backwards compatibility, but it should be more visible when it happens. Compare the way that Chrome is moving towards labelling sites as Not Secure when they don't run TLS but you can still access them, whereas when MS finally took steps to stop applications from writing to Program Files (which they told developers not to do from day 1), they just silently and unreliably redirected to the rear end end of the file system, instead of popping some kind of "this application is doing something really dumb and if you haven't spent any money on it yet don't sign a contract unless you like working with poo poo software" warning.
|
|
#
?
Oct 17, 2018 22:38
|
|
|
Scikar posted:I don't think MS should immediately give up on backwards compatibility, but it should be more visible when it happens. Compare the way that Chrome is moving towards labelling sites as Not Secure when they don't run TLS but you can still access them, whereas when MS finally took steps to stop applications from writing to Program Files (which they told developers not to do from day 1), they just silently and unreliably redirected to the rear end end of the file system, instead of popping some kind of "this application is doing something really dumb and if you haven't spent any money on it yet don't sign a contract unless you like working with poo poo software" warning.
|
|
#
?
Oct 17, 2018 22:51
|
|
|
EssOEss posted:At least 4.7.1 still has idiotic issues with Microsoft assemblies like System.Runtime not loading. I gave Rider a try for a little bit and regretted it and went right back to VS + ReSharper (with VS Code for quick changes).
|
|
#
?
Oct 17, 2018 22:55
|
|
|
I have a C++ Win32 program that processes lots of data as it is generated and renders it as pretty graphs. I want to port it to .NET Core because writing and distributing C++ for multiple platforms is just hateful, I need it to run on Linux and quite enjoy C#. I hoped to take advantage of the rewrite by redoing the GUI as a fancy Javascript thing because i'd like it to make it more modular/extendable (eg: allow people to write their own renderers/workers) and that seems like a good way of getting around the relative immaturity of cross-platform GUI offerings for Core. The only thing I can see that might meet the requirements is Electron .NET. The examples I've seen look a lot prettier than Qt (which I'd be moving away from) but A: it's .NET running in Electron, so it needs separate distributions for each OS (I guess I can deal with that, still easier than C++) B: everyone here seems to think that Electron is not only the worst thing that has ever happened to programming but is also horribly slow - which will probably hurt a lot bearing in mind the existing performance hit from going from native binaries to JIT. Are there any better alternatives? Am I just trying to do something which is a bad idea? If that fails - is Qt relatively usable for Core? thanks!
|
|
#
?
Oct 17, 2018 23:03
|
|
|
Munkeymon posted:I don't understand the distinction you're making between a 'reference' and a 'dependency' here and maybe I'm not the only one? One is right-clicking on References and choosing “Add a Reference” and picking the DLL. This is what I do when referencing my library from a different solution. What apparently fixed my problem is an additional step that I took which was right-clicking on my test project there’s an option somewhere in there to add a dependency. This option doesn’t appear if there is only one project in the solution. Adding the dependency in addition to adding the reference (which is required to use the library at all) is what seemed to fix my problem with pack uris.
|
|
#
?
Oct 18, 2018 00:13
|
|
|
|
| # ? Jun 1, 2024 21:34 |
|
|
The issue arises because you use a DLL/assembly reference to the output of a project in your solution instead of using a project reference - without explicitly telling VS that there is a dependency it doesn't know that the project happens to generate the referenced DLL*. The consequence of this is that VS will happily compile both projects in parallel instead of the actual required build order, resulting in a race condition of whether the referenced DLL will still (or already) exist when the referencing project is built. Usually this results in weird build errors where a namespace that clearly exists cannot be found during compilation or where a DLL mysteriously cannot be copied to the output folder. I guess the Pack URI mechanism needs to access the source assemblies at some point during compilation and silently fails if it can't, resulting in broken resource images. * Technically it likely could deduce that is the case, but honestly it's probably better it doesn't. Unless such heuristics are rock solid they just lead to random issues or broken behavior in edge cases. At most I'd have VS generate a clippy-like notification that it detected this case and whether to fix it, but not automagically assume stuff behind the scenes.
|
|
#
?
Oct 18, 2018 09:34
|
|