I've been playing around a bit with MVC 6 and a few other of the newer web development tools (Angular 2.0, etc.) and I've run into a bit of a problem setting up a webpage that utilizes MSMQ. For reference, I'm using VS2015 Update 2, which I believe is still RC1.
When I first tried to mess with System.Messaging in general, it kept having issues with Nuget Packages (which was a bug with Update 2, it required an update to the Nuget service) and wouldn't reference the package properly. After playing with it some more, I eventually got the package referenced (had to do it manually in my solution explorer) and any errors Visual Studio originally would have detected seemed to be resolved. Now, I get errors on build stating that it can't find a reference (to System.Messaging). I'm not sure if this is an issue with my solution or if it is something that VS2015 is having issues with.
From what I've read (I'm coming from WCF), MVC 6 is a much better way to handle these sort of situations so I'm trying to make the switch but this has me completely dead in my tracks.
If there is any specific way I need to do messaging queues in MVC 6/ASP.NET Core 1.0 I have not found it, so any sources or advice on this is greatly appreciated.
Unless you specifically need to target multiplatform with the .net core DNX, you could still write your app with all of the new hotness features of MVC6 and the DNX, but still target the classic full .Net 4.5.1 (or whatever version you need).
Open your project.json file and find the "frameworks" portion of it, and remove the reference to "dnxcore50" so that the final section becomes the following.
"frameworks": {
"dnx451": { },
},
At that point you should be able to reference System.Messaging without issue.
Related
I have a custom authentication component that is working with net core 2.2. I've started migrating the project to net core 3, but it seems like MS hasn't updated the authentication Nuget packages.
Until now, I was referencing the Microsoft.AspNetCore.Authentication package. The package still exists, but hasn't been updated to net core 3.0 (it's still on the 2.2 version).
I can't keep using it because net core 3.0 has moved the RequestPathBaseCookieBuilder type to a different namespace (so, at runtime, I'll get a tyoe loading exception). A quick search shows that only the Microsoft.AspNetCore.Authentication.OpenIdConnect has been updated to net core 3.0 (and if I add it to my project, then my component to work without any issues).
Anyone knows why MS hasn't still updated the other security nuget packages to version 3? Is there anyway to solve this without using the openidconnect nuget package (I'm only using it because it was the first that was updated and it will bring the correct Microsoft.AspNetCore.Authentication assembly that I need for my project)?
Looks like I was 10 minutes too late, but you posted the answer as a comment, rather than an answer, and I like questions having answers so I stop opening them when browsing the question search results.
Anyway, as you discovered, .NET Core 3.0 no longer uses packages for base class libraries (BCLs). Instead, they're just part of the SDK, so by targeting netcoreapp3.0 or netstandard2.1, all BCLs are just available. This should eliminate a lot of problems that earlier .NET Core projects had, particularly when referencing .NET Standard 1.x assemblies from netcoreapp2.x tfms. Although the largest benefit will be when all referenced packages target netstandard2.1 or netcoreapp3.0 or above.
Ok, so finally got it. The solution is to use the FrameworkReference element with the Microsoft.AspNetCore.App meta package.
I have a somewhat weird problem:
I have installed Visual Studio 2015 and 2017 RC on my system, as well as Asp.Net Core 1.0 and 1.1
I have build a new Solution, containing a new Asp.net Core 1.1 Project - called Upload
Now I want to add an Xunit Test Project, which can be done either from the CLI or via menu, I tried both.
This project has the following dependencies:
But now the whole solution fails to compile, b/c Xunit seems to be netcore 1.0, whereas my project is 1.1?!?
How can I solve this? I am unsure if I have installed something wrong, or if there is another rational explanation.
After a lot of digging into GitHub issues and other SO posts I finally fixed the issue by following the direction of BalassaMartin here.
TL;DR: install the Microsoft.NET.Test.Sdk NuGet first.
My guess is that xunit.runners.visualstudio references a previous version of Microsoft.TestPlatform.ObjectModel that does not target .NET Core. Adding the Microsoft.NET.Test.Sdk
package solves the problem because it references the 15.0.0 version.
After doing this the xunit.runner.visualstudio package installed fine. However now I'm back to the classic problem of not being able to actually see my tests in the explorer because VS can't find them.
I'll update when solved if the visibility issue is relevant to OP
Update
The reasons I still could not find tests was a dotnet core version mixup. Its likely to happen to a lot of people. See SO post for solution.
I am new to this area. I already upgraded my VS2015 with update 3. So now I have: .Net Core 1.0.0 with preview tool 2 installed.
Then I use VS2015 to create a new .Net Source project (class library). I have copied some existing .net 4.6.1 code to the new place and compiled error as expected. Then I use "porting analyzer tool"(https://learn.microsoft.com/en-us/dotnet/articles/core/porting/index) to compare and it did give some suggestion how to use the new way in .Net Core.
But there are still few class missing and cannot compile, like 'TypeDescriptor' or 'NullableConverter' etc. Then I googled and someone from Github say they already added these feature but I still not sure why I still get compilation error.
I also noticed that my class libary project has a project.json file as:
"frameworks": {
"netstandard1.6": {
"imports": "dnxcore50"
}
}
I foundn if I remove the 'netstandard1.6' one but change to:
"frameworks": {
"net461": {}
}
All the compilation error gone, but I could guess it's NOT .Net core project anymore, and more likely as a standard .Net 4.6.1 project.
So basically I'd like to ask:
Why developer from Github saying that is fixed already but I still couldn't find/compile those classes in my project (e.g. TypeDescriptor : https://github.com/dotnet/corefx/issues/8262)?
Some sample also puts both 'net461' & 'netstard1.6' or 'netcoreapp1.0' under 'frameworks' in project.json file. What's the purpose for that?
If I just use 'net461' for the only framework, there seems no difference to traditional .Net Framework 4.6.1 project. Am I correct?
Thanks a lot!
Install package System.ComponentModel.TypeConverter and you are good to go with .NET Core project.
For building different output (binaries) each of which targeting different platform. net461 for applications which should run on (full) .NET Framework (under Windows or Mono). netcoreapp1.0 used for app which should be run under .NET Core. netstandard1.6 (avoid using netstandard1.5 and netstandard1.6 by the way - use previous versions) used for portable class libraries, which are supposed to run under different platforms: (full) .NET Framework, .NET Core, Xamarin, Universal Windows App, etc. You may read more about here and here.
Absolutely.
I have an application that consists of a client-side application and a WebApi website.
My client-side stuff is targetting .NET 4 so that I don't have to insist that users install .NET 4.5. My website, however, is entirely under my control, so I'm targetting .NET 4.5.
There is one shared assembly, which I use for data access. It uses Entity Framework 5.
When I build the client application, the DLL used is version 4.4.xxx, whereas when I build the web application, the DLL is 5.0.xxx.
Up until now, I've been able to run the client application with no problems, and I've also been able to run the web application, again without problems.
However, I've now re-created my web application project from scratch (*), and suddenly I can't run it. I get a YSOD saying "Could not load file or assembly 'EntityFramework, Version=4.4.0.0 ..." at the point where my data-access assembly is first invoked.
Now, it's perfectly clear what that error means - it can't find the v4.4 DLL as used by the data-access assembly - but I don't understand why that's a problem with my new project when it wasn't a problem with my old project. As far as I can see, the same DLLs are referenced in each project.
(*) I should explain why I'm re-creating my project. I originally created the project in VS 2012 RC, and then later upgraded to the release version. Although this supposedly upgraded my project, I've had a few problems with it, and have also noticed some differences v. a newly-created project. So, to be on the safe side - and hopefully circumvent those other problems - I'm re-creating it from scratch.
So, my question: why is this suddenly a problem, and what can I do to resolve it?
Is the code depending on the assemblies set to require the exact version? If so, you will need a publisher policy for the EntityFramework assembly or bindingRedirect for the referencing application (web project).
After allowing Nuget to update ImageResizer 3.1.5 to version 3.2.1 my compiles are failing with multiple errors (all same type):
Error 5 Missing compiler required member 'System.Runtime.CompilerServices.ExtensionAttribute..ctor'
Apparently this is the result of an assembly version mismatch. Deleting all ImageResizer references in the project allows an error-free compile.
Reverting to ImageResizer 3.1.5 also allows a successful compilation.
My project is a simple MVC3 application targeting .NET4 - both ImageResizer 3.1.5 and 3.2.1 are targeting v2.0.50727
Any ideas on how this could be fixed?
Thanks in anticipation!
Update (Jun 20th 2012): The best solution is for the project to roll back extension method support. ImageResizer 3.2.2 will no longer offer extension methods, but some of the functionality will be duplicated in the ResizeSettings and Instructions classes to minimize breakage for those who have already coded against the new alpha APIs.
ImageResizer V4 will most likely require .NET 3.5, and will re-introduce the missing features.
Update: please see this question instead if you have any solutions to this catch-22.
I apologize for the issues.
I'm still trying to gather data and discover a long-term solution, but this is what I have so far:
Workaround A:
In Solution Explorer, expand the References folder in your project, select ImageResizer, and go to Properties. Change the Aliases field from 'global' to 'ir'.
Workaround B:
Set your project to use .NET 2.0, save, then revert it back to using .NET 3.5 or .NET 4.
Workaround C:
Manually remove your System.Core reference and add the correct one back. (The usual culprit is an upgraded project with a System.Core 3.0 reference in a 3.5 project). On ASP.NET, you can do this in web.config.
Workaround D:
Revert to 3.2.0, but only if you're using C#.
Why this is happening
VisualStudio/MSBuild find multiple definitions of System.Runtime.CompilerServices.ExtensionAttribute in the project during compilation, but instead of picking the public copy defined in System.Core, the compiler decides to use the internal, assembly-local copy defined in ImageResizer.dll. Then it complains because other assemblies can't reach it. Inane.
What should happen
Microsoft has used this technique several times in the past without issues, and it's widely documented. The compiler is supposed to pick the public instance for project-wide use, but instead it's picking the 'internal' copy. And this isn't affecting many developers; and only a few can reproduce it with a new project.
Public vs. Internal
V2.3.0 defined ExtensionAttribute as public instead of internal. This caused a compile-timer error in VB projects, but not in C# projects. I immediately released 2.3.1 with it marked internal, but I'm now seeing problems with C# projects instead. Catch-22 here.
It works for other people... and Microsoft! Why me?
http://www.danielmoth.com/Blog/Using-Extension-Methods-In-Fx-20-Projects.aspx
http://www.codethinked.com/using-extension-methods-in-net-20
http://kohari.org/2008/04/04/extension-methods-in-net-20/
Using extension methods in .NET 2.0?
The 'hack' was even featured in MSDN magazine.
How you can help
I need more data to completely figure this out. If you're experiencing the issue, please e-mail a .zip file of the project to support#imageresizing.net, and include your VisualStudio/.NET version numbers (Go to Visual Studio, Help, About, and click Copy Info, then paste it into the e-mail).
Hopefully I'll be able to find the exact circumstance(s) that trigger the problem.
Update - just found this article which implies the only solution is creating multiple versions of the assembly. But Microsoft didn't! What am I missing? Also, NuGet doesn't support 2.0 vs 3.5 versioning, so unless I can find a single-assembly solution I might have to drop 2.0 support.