I'm trying to tinker arround with ASP.NET5 and all the new Magic we get.
I created a small Application, which receives a MAC-Address and sends a WakeOnLan-Package. For the abstraction of the WoL, I tried to use the SharpPCap-Library: http://www.codeproject.com/Articles/12458/SharpPcap-A-Packet-Capture-Framework-for-NET
I can add the References and even set the Object, but it seems only be avaliable on 4.5. Simply put, do need Asemblies be compatible to DNX 4.5.1 AND DNX Core 5.0?
I tried to add the Automapper, which works, but this one is shown on both Reference-Folders DNX 4.5.1 and 5.0. Does this mean, this Assembly is kindahow working on both Versions? If yes so, how is this possible, if other Assemblies don't seem to be compatible?
My 3. question raises from the Project-References: I added the Model-Project to my WebGui one, but Intellisense keeps marking the Model-Objects red and telling me, he can't resolve it. Funnily enough, building and Runtime work perfectly fine. Is this an issue of the Compiler atm?
If you have any resources on the general topic, I would be glad as well. I found some threads about this theme, like Jon Skeets problem: How can I diagnose missing dependencies (or other loader failures) in dnx? or the diagnosing: http://davidfowl.com/diagnosing-dependency-issues-with-asp-net-5/ but I guess, my problem is on a more basic level.
Thanks in advance.
You don't need DNX Core 5.0 - that's all the .NET Core stuff which SharpPCap probably isn't compatible with. If you can, just get rid of that framework like this in your project.json file:
"frameworks": {
"dnx451": {
}
},
It's probably the same thing for your Model-Project. getting rid of dnxcore50 should help. Basically by doing that you are saying your project needs full .NET, so it might not be as easy to run it on Linux etc...
The red line issue might be a re-sharper problem if you're running that?
see: Dnx 4.5.1/Dnx Core 5.0 Ambiguous reference
Related
I have used the try-convert tool to convert my projects from .NET Framework to .NET 5.0
When inspecting the converted *.csproj files for projects that are targeting .net50-windows I noticed the element:
<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>
I am curious to understand what it does?
Is this essential or another example of something that try-convert puts in the *.csproj but is not really required to be present in the *.csproj any more?
Thanks.
The same happened when I used upgrade-assistant to do the upgrade and I also
wondered what the ImportWindowsDesktopTargets means and whether I needed it. I could find no official documentation for it, only this discussion. According to the question in the discussion, adding an ImportWindowsDesktopTargets property is one way to allow multitargetting using the TargetFramworks property, like this:
<TargetFrameworks>net472;net5.0-windows</TargetFrameworks>
<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>
As my project does not need to target multiple frameworks, just net5.0-windows, and as I have other projects, both Windows Forms and WPF, that target only net5.0-windows and work fine without ImportWindowsDesktopTargets, I removed ImportWindowsDesktopTargets from the converted project with no problems.
According to the proposed answer in the linked discussion, even if you do want to target multiple frameworks, there may be a better way to do it.
This is for pre-Net5.0 behavior to force importing WindowsDesktop Targets.
If you are using Net 5.0 or a newer version, Microsoft.NET.Sdk.WindowsDesktop will always be imported by the SDK, so you may remove it.
I am migrating to RavenDB 4.0, as a part of Migration I came across setting the meta-data session.Advanced.GetMetadataFor(data)["Raven-Expiration-Date"] = new RavenJValue(data.Promotion.DateToUtc);
The only place I found that type is Raven.Abstractions reference, but that on is in version 3.5 Is that still valid for 4.0?
Also, I am not sure if that Raven.Abstractions package comes together with RavenDB 4.0 package, and it looks like those things depend on each other.
Anybody has any kind of experience with that? I understand RavenDB 4.0 is not final yet, and there might be some of the issues.
Thank you.
That value has changed. For 4.0, you need to use:
session.Advanced.GetMetadataFor(data)["#expires"] = data.Promotion.DateToUtc.ToString("O");
I'm trying to run a .NET MVC application on my local computer that I got from GitHub.
When I hit run on Visual Studio, everything complies and a new browser window opens with the error:
CS1980: Cannot define a class or member that utilizes 'dynamic' because the compiler required type 'System.Runtime.CompilerServices.DynamicAttribute'
The compiler section in the same window, shows the following error:
I've checked on google and this seems to be the same error.
This guy was using a dynamic type himself, on the other hand I'm not using any dynamic type, this is being auto generated by .NET's compiler, and I'm using .net 4.5 which should has support for dynamics.
I tried to apply the same solution (Changing all System.Core references to 4.0)
but the thing is that all of them are version 4.0 already.
Do you have any idea how could I resolve this?
I had a similar error on a project I was trying to migrate. Try re-targeting the framework of the project back a version or two, and once you find a target version where you do not get the error, re-target back to the version you originally had trouble with.
I was getting the same error on a website project targeted for 4.6.2 that was referencing some older libraries, re-targeted it back to 4.5.1 and that resolved the error. I immediately re-targeted back to 4.6.2 and did not encounter the error again.
I had this same issue, but none of the answers here solved it, but did point me in the right direction. I think I didn't update the .NET version on my machine to the newer one. After installing it, I rolled back the targeted framework (as was suggested), retargeted the newer framework, and did a few extra things also:
Reinstalled ALL packages by running this in the package manager:
update-package -reinstall
I also compared my project to one that was working for 4.5 and did this:
Opened my project file and removed all "BCL" related elements.
Uninstalled all "BCL" packages in the NuGet package manager for the project (guess it's not needed moving to 4.5+...?)
Removed an old package version of System.Net.Http, which did not get updated for some reason (see web.config - versions should show oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0").
Have to restart VS.
Rebuild solution.
Error is now gone. ;)
One other thing I did to resolve some other errors was to clear the component cache by deleting all files in here:
C:\Users\{USERNAME}\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache\
[rant] Wasted a whole day with all this. Thanks to MS for stealing one more day of my life fixing senseless issues that should never be. Every time I upgrade I always get a wonderful surprise, and a lovely game of fix the red herring. Would it not hurt to detect these conflicts for those upgrading old projects? Perhaps better error traces when things go wrong? I doubt it would be that difficult. Perhaps even something like AsmSpy, but more advanced, built in to VS? [/rant]
Saw this in VS 2019. I excluded and re-included the problematic file (in my case _Layout.cshtml) and that fixed the problem.
I got this error suddenly a couple days after updating to VS2015.3 using 'traditional' MVC app (not new .NET Core / vNext app).
Turns out this error can be a complete red herring.
Make sure:
You haven't got any other errors at all
You've checked the output window for any errors that don't show in the 'Output' window.
Make sure you don't have any conflicting references
In my case I had a typescript error that was causing an error and for some reason triggering this weird 'red herring' dynamic error too.
My fix was to go into the .csproj file and update the typescript tools version to 1.8 (need to unload project and edit by hand). As I said this is unrelated to the error, but I mention the specifics because someone else may end up with this same problem.
I believe that 1.7 didn't accept 'None' for the typescript module system whereas 1.8 does, hence the error.
Adding a reference to System.Dynamic.Runtime did it for me.
I hesitate to write this as an answer, but for me the error appeared in a .cshtml file. I closed the page, rebuilt, and the error vanished. Always best to try the simple things first.
I had the same error, there were just 2 unused tables of my databaseset that I had to delete. I wonder why it worked when I manually change sth in an auto-generated code work but after deleting, it worked.
So be aware that such inconsistencies can also cause this error.
My solution was to correct the version of MVC in web.config under Views folder. E.g. the project referenced MVC assembly version 5.2.2.0 but in the Views/web.config file was version 5.2.4.0 (see image).
Image
Tried a few other answers with no luck, but the overall consensus appears to be that this some sort of issue with cached build artifacts or compiler state or something. Here's what worked for me:
Delete the problem .cshtml file, watch error disappear
Open source control and revert the deletion
This error will come because of the different versions of your Sitecore.Web.Mvc.Dll in solution reference folder(Project name->References->Sitecore.Web.Mvc->right click and check properties) and the version of Sitecore.Web.Mvc.Dll in Web.Config in views Folder.
For solving this error you have to make sure that the version of Sitecore.Web.Mvc.Dll is same in both folders.
Thanx.
For my case, I fixed to run the command line "update-package -reinstall" on the Package Manager Controler.
My problem was in the _Layout.cshtml.
None of the solutions above did the trick for me. I am using VS2017 for this project, upgraded an ran into the same message.
I had commented out a 2 lines in 1 comment #* *#
My solution was to comment out each line separately. What a mystery!
A few hours lost on this.
My C# WinForms solution has two projects.
A DLL which is the main project I'm working on, and an executable WinForms I call "Sandbox" so that I can compile/run/debug the DLL easily in one go.
I'm working in .Net 4.0 for both projects.
Everything was working fine until I added some seemingly innocent code, and a reference to System.Web in the DLL.
Now my Sandbox project can't see the namespace of the DLL project. I didn't change anything which I believe should have affected this.
If I delete the project reference to the DLL from the Sandbox references and re-add it, then the red underlines all disappear and the colour coding comes back for all my classes etc; but as as soon as I try to build the solution, the whole thing falls apart again.
When I right-click the DLL project in the Sandbox's references and view in object browser, I can see the namespace and all the stuff in there.
I have a feeling this might be some sort of bug?
Is this some sort of VS2010 bug? I had this same issue a few months ago and I could only fix it at the time by making a whole new project and re-importing my files. This time, however, I have a bajillion files and will only do that as a last resort!
Edit:
After panickedly going through and undoing all my changes, trying to find what caused the problems, it seems to be this line:
string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);
If I comment out this line, then I get no namespace errors and the project builds fine. I can't see anything wrong with this line though.
I'm ready to declare this a bug in VS2010, this has bitten way too many programmers already. The fix is easy: Project + Properties, Application tab, change Target Framework to ".NET Framework 4" instead of the Client Profile that is selected by default.
System.Web is not included in the client profile. Having this option in the first place is quite silly, the client profile is only 15% smaller than the full version of .NET 4.0. Having it selected by default is even sillier. But I digress.
UPDATE: mercifully this all got fixed in VS2012. Which no longer makes the client profile the default for a new project. And the client profile got retired completely in .NET 4.5, good riddance.
Check to make sure that both projects are using the non-client profile for their target framework (go to each project's properties to do this).
One possibility is that the target .NET Framework version of the class library is higher than that of the project.
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.
Try building only the project with the Sandbox dll first independently.
Then point your executable project to the required dll and ensure copy local is set to true. in reference settings.
Tthen build the executable project.
Changing the target framework from the ".NET Framweork 4 Client Profile" to ".NET Framework 4" worked for me with a similar problem. I agree that the client profile doesn't seem to have much of an advantage to using it. I seem to get nailed with weird errors that I hunt for until I remember that Visual Studio defaults to the client profile. I guess the moral of the story when getting an error is: if "Rebuild Solution" doesn't work, check the Target framework...
If you tried already doing the Framework change, and still not worked, I hope this works for you (as it did for me): Simply add the necessary references from within your projects. Very obvious but I was doing it wrong until I found what was the issue.
I just had this issue and it turned out to be I had multiple namespaces being used that had the same object name (i.e. business objects had the same names as mvc models);
Fully qualifying the names fixed the issue for me.
I have this c# project...i add this reference (a dll) to it, and try to use that library in my code.
I use what its called (its a database connector)
MiDB myDb;
it doesnt find that, i can right click and say "resolve" usings... that adds this line to the top:
using ThePackage.Database.AoNM.MiDB;
blah blah
So this works, it sees it, i can even then call a method that is seen:
myDb.InitDB("stuff here");
bingo. the minute I build this, it says it cannot find ThePackage, and its like that usings, or reference doesn't exists. In the solution explorer it is still there? I can remove the reference and add it again, and then this same thing happens, it "seems" like its there, but going to build and run it "goes away".
It might be cause its late, but I am honestly totally lost as to why C# (2008) is doing this to me?
DLL was built in 2008 to... maybe im missing some build option with the dll?
Check that the dll and the assembly run on the same CPU type (x86-x64). I used to have similar errors (and very strange error messages) when they were different.
I had same problem.
You need to change target framework of your project from ".Net Framework 4 Client Profile" to ".Net Framework 4"
It worked for me.
if the dll is using a higher .net framework version than the application, you would see this. it's probably unlikely the way i read what you said in the comment in that the application is in visual studio 2010 and the dll was built with visual studio 2008. not completely sure that's the case, though, as the quesiton cites visual studio 2008. anyway, check that you are using the same framework version or greater in the referencing project as in the referenced.