Last post Aug 01, 2016 04:08 AM by kruddler
Aug 01, 2016 01:30 AM|Kruddler|LINK
I built a Web API ASP .Net Core (.Net) project and I'm trying to figure out why it is throwing an error. It has all the same code as our WCF Services, and yet it throws an error that doesn't happen in WCF. My question isn't in regards to the error, my question
is why the debugger is not attaching to the lower level library.
Here you can see that the debugger is attached:
But, when I step over this line, I get the exception. However, the debugger doesn't break on the actual line of code where the error is happening. This is what I see:
When I look at the lower level method, I don't get the healthy red dot. I get a hollowed out dot probably indicating that the app is not using the same DLL that I am trying to debug:
So, why isn't the debugger recognising this lower level DLL? My debugger is set to break on all errors:
It's as though IIS express is picking up an older version of the DLL from somewhere. But, I've tried cleaning and rebuilding etc. I've also cleaned out the Temporary ASP .Net files. I'm stuck.
Aug 01, 2016 01:38 AM|Kruddler|LINK
This is very much looking like a project structure problem. I realised that IIS express has a different assembly cache folder (C:\Users\[username]\AppData\Local\Temp\Temporary ASP.NET Files). So I deleted these files. After that, the project stopped compiling.
Failed to make the following project runnable: Adapt.REST (.NETFramework,Version=v4.6) reason: Could not find file 'C:\AdaptSource\AES\Adapt.Presentation.AES\Bin\Adapt.Data.Generic.dll'. Adapt.REST C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets
I don't really understand why as this assembly is referenced as a project. I don't know why it was picking it up from the cache, and I don't know why I'm getting this compilation error.
Aug 01, 2016 01:40 AM|Kruddler|LINK
This looks like some kind of bug in the new xproj format. I remove the project Adapt.Presentation.AES from the solution which is completely unrelated, and now I can compile.
Aug 01, 2016 01:41 AM|Kruddler|LINK
Despite this, I still have the same debugging problem. I think that IIS is still picking up the wrong DLL from somewhere but I've got no idea where it is picking it up from...
Aug 01, 2016 01:51 AM|Kruddler|LINK
I can prove that it is using the wrong DLL now. I put an exception in the code in the lower level library and reran the code. The exception is not thrown. This means that IIS Express is latching on to the wrong DLL. Why? How do I stop this?
Aug 01, 2016 02:59 AM|Kruddler|LINK
This gets worse.
ASP is clearly not picking up the changes to my DLL. I've added a property at the data layer level and then referenced it from my MVC controller. Now, the Get method doesn't even get hit. When I comment out the code, the Get method gets hit. It's as though
ASP at runtime notices that it can't compile because it's trying to compile against an older version of the DLL, and then it just errors without ever passing control to the Get method.
Aug 01, 2016 03:03 AM|Kruddler|LINK
I did a rebuild on the solution, and the DLL in question isn't getting refreshed in the bin folder. It's in the folder "bin\Debug\net46\win7-x64". I assumed that this would work like other .Net solutions, but it appears something is different here. Why is
not getting cleaned and rebuilt on the solution rebuild?
Aug 01, 2016 03:09 AM|Kruddler|LINK
I hunted around for the old DLLs and deleted them. Now, I'm back to this error:
Severity Code Description Project File Line Suppression State
Error Failed to make the following project runnable: Adapt.REST (.NETFramework,Version=v4.6) reason: Could not find a part of the path 'C:\AdaptSource\AES\Adapt.Presentation.AES\Bin\Adapt.Data.Generic.dll'. Adapt.REST C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets
Where does Visual Studio think it should be picking the DLLs up from? I removed the project it is referring to from the solution. Why does it think it should get DLLs from there? I'm at a loss here.
Aug 01, 2016 03:26 AM|Kruddler|LINK
This new xproj format doesn't even allow us to specify an assembly references path.
God knows why it's trying to pick the assembly up from a path that's not even in the solution.
The new xproj format is full of bugs.
Aug 01, 2016 03:35 AM|Kruddler|LINK
So, I've tried removing the reference as a project, and then adding a direct reference to the DLL. I get this:
It thinks that it's not a .Net DLL. Why? It's a .Net 4.6 framework DLL. What's it's problem?\
BTW: This a .Net ASP Core project. All the other DLLs are .Net 4.6 and all the other DLLs are referenced correctly.
Aug 01, 2016 03:53 AM|Kruddler|LINK
I created a new .Net 4.6 class library project and compiled it. I then tried to add the DLL from my ASP .Net Core project. It just errors with the error message above.
What is going on?
Aug 01, 2016 03:55 AM|Kruddler|LINK
Just a sanity check here, shouldn't I be able to add references to .Net DLLs in an ASP .Net Core (.Net) project?
Aug 01, 2016 04:08 AM|Kruddler|LINK
I googled this problem and found this link:
Basically, it's saying that I should downgrade my NuGet reference to .NetStandard.
Well, I wasn't referencing it, so I added the NuGet reference. I noticed that the .NetStandard reference is 1.6. This is absurd because this article says that if I want to reference .Net Standard, I need framework 4.6.3. That's going to be very difficult
seeing it is not even released yet.