Object reference error after ASP.NET 5 Web Site creation - asp.net-core

When using Visual Studio Enterprise RC to create a new .NET Framework 4.6 ASP.NET Application using the Web Site template I am receiving an object reference not set to an instance of an object error. After dismissing the error the project seems to be ok, but I would like to be sure.
Both the Empty and Web API template work fine.
I have tried creating the project with Visual Studio in safe mode as well as creating a new project with a separate instance of Visual Studio attached for debugging. None of this has given me a clue as to what the problem might be.
Any idea what could be causing this issue? Or pointers on next steps to take?

You can now upgrade to the full Visual Studio RTM version. That should fix your problems.

Related

Visual studio 2017 showing Errors for Blazor but compiles

EDIT:
Found issue to be resharper. When I disable it it stop showing errors.
When I start a new Blazor fullstack project from Visual Studio it shows error in IDE. I have looked at Visual Studio displaying errors even if projects build but doesn't seem to help.
I followed the guide on Blazor (https://blazor.net/docs/get-started.html)
But the client side project shows lots of errors
EG:
and more details:
and:
Any one else tried this and know how to fix it?
I am running VS Studio Enterprise 2017 Version 15.8.8
I have installed ASP.NET Core Blazor Language Services.
Everything seems to work as it should. I was able to add new page with external RestAPI calls and all.
Edit:
Updated VS to latests version with no luck
Seems it might be resharper:
https://resharper-support.jetbrains.com/hc/en-us/community/posts/115000554550-ASP-NET-Core-Razor-Pages-page-Cannot-resolve-symbol-
Well. Seems that jetbrains is aware of issue.
It can be found here:
https://youtrack.jetbrains.com/issue/RSRP-469186
Not much to do than disable Resharper for the moment and wait for them to fix it :)
If you need help to disable and enable it again:
How can I disable ReSharper in Visual Studio and enable it again?

Visual Studio online build failure for an empty universal app

I just created a new empty universal app (windows 10) and checked it in on my visual studio online project.
The configured build is constantly failing on following error...
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.CSharp.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
I set build configurations to use VS2015 but without any luck.
I keep thinking there's a simple configuration I'm missing here... but can it also be that it's not yet supported?
The project itself is just the standard template from Visual Studio.
I'm having a similar issue running with MSBuild 8.2 target missing under VS2013 Update 5 under Windows 10 TH1. Except my target is Microsoft.Windows.UI.Xaml.Cpp.targets. So not necessarily an issue with Visual Studio but rather the substitution for $(TargetPlatformVersion) in the targets definition:
<Import Project="$(TargetPlatformVersion)\Microsoft.Windows.UI.Xaml.Cpp.targets" />
I'm building a project from Microsoft (https://github.com/Microsoft/winsdkfb), so I don't think this is your problem (meaning you've not done anything incorrect).
I know this isn't an answer, but I suspect we're caught in a gap in the Windows 10 SDK & Tools. Those aren't scheduled to be complete and available until 29 July even though VS2015 has RTM'd. I tried to track down something in the VS2015 release notes without luck.
Just inform the solution I found on this thread.
At the time of writing, it appeared that VSTO serves were not yet updated with
the Windows 10 SDK.
The only way back then to make it run was by creating your own Build VM (through Windows Azure) and link it to your VSTO builds.
I posted the thread and got the answer on the MSDN TFS forum.
I have not tried it right now, but since Windows 10 is officially released now, I guess it may work out of the box.
We now support building Universal Windows Platform (UWP) projects on the hosted build service.

Can't open project in Visual Studio 2013 Express - Framework issue

So I have a program I've been making in VB for my company through Visual Studio 2013 Express for Desktop and have not worked on it in a couple of months. When I try to open it, I get the following error:
"The VB project "WindowsApplication1" is targeting ".NETFramework,Version=4.5" which is not installed on this machine."
http://imageshack.com/a/img661/6001/DGAfuk.png
I have all of the .NET frameworks installed including all developer and service packs (even language packs). I uninstalled all .NET frameworks and re-installed each of them without any resolution.
I tried to re-install Visual Studio and even tried changing the Framework (one of the options I have) but I cannot view any code or open designer view if I do so. (http://imageshack.com/a/img633/2109/OJaXbr.png)
The strange thing is this computer is the same one I have been developing this application on for months, so I'm not sure what happened over the last 60 days since I launched it.
Does anyone have any clues as to how I can resolve this issue?
Thanks in advance,
Matt
The path to your project must be Les then 256 Character.
That can be the reason of it.
Make sure the path is short "Copy the project to your c drive "C:\ProjectFolder" and try again".

mvvm-light : losing intellisense on VS2012

We are using MVVM Light Toolkit (from Galasoft - Laurent Bugnion).
Until now we were using Visual Studio 2010.
Everything was working well (thanks to Laurent).
Two days ago we moved to Visual Studio 2012.
And now Intellisense is no longer working in Xaml files (but still working in code-behind).
After looking on forums and made some tests, it appears that we have an issue with "GalaSoft.MvvmLight.Extras.SL5.dll".
As soon as GalaSoft.MvvmLight.Extras.SL5.dll is removed from project references, intellisense is working again.
Someone already had same problem and/or know a solution ?
Thanks.
Alain.
We had a similar problem when we migrated from Silverlight 4 to 5. We were using a local copy of GalaSoft.MvvmLight.Extras.SL5.dll copied from another computer.
Once we installed the MvvmLight .msi package and changed the reference in our Silverlight project to C:\Program Files (x86)\[...]\GalaSoft.MvvmLight.Extras.SL5.dll, IntelliSense started working again.
Hope this helps

.net 4 debugging api causes access violations in debugee

is there any way the .net 4 debugging api can somehow corrupt the state of an application during startup?
the issue i have is the following:
if i start my application from within a debugger using the .net debugging api (visual studio 2010, sharp develop 4, mdbg), i get various random access violations.
if i start my application from within a debugger not using the .net debugging api (delphi 2007, windbg with sos extension) everything works fine.
if i start my application directly and later on attach a debugger to it (like visual studio 2010, sharp develop 4, mdbg, delphi 2007, windbg), everything works fine.
if i move back to .net 3.5 and clr 2.0 i have no problems at all.
so what changed from .net 3.5 to 4.0 in the managed debugging api causing my application to throw access violations if started with it?
the application is written in delphi (unmanaged) and c# (managed) using managed vcl to do the interop.
i can hardly give any example to reproduce this issue so i'm aware that answering this question might be impossible, but if someone with more insight to the debugging api can give me a hint in the right direction or could help me narrow it down i'd be very thankful.
Just for fun try and disable the Visual Studio hosting process. In Visual Studio right click on the project, go to the 'Debug' tab, and uncheck the "Enable the Visual Studio hosing process" check box.
We've seen some strange stuff in the managed/unmanaged land on 64 bit systems running 32 bit apps.
Some additional info based on experience: It is important to use the COMPLUS_MDA environment variable (remember to restart VS2010 afterwards), not the MDA registry key. I tried setting the registry key (followed by restarting the computer) as described by the MSDN article http://msdn.microsoft.com/en-us/library/d21c150d, as the article indicated this should have the same result, but that didn't work.