Conflicts between copied VS solutions - asp.net-mvc

I'm experiencing some strange behaviour with my ASP.NET MVC 5 application, running on Visual Studio Ultimate 2013, in Windows 8 Professional, and using MongoDB 2.6 as the database.
Originally, there was one solution; let's call this Alpha. Then, I copied the solution (literally copied and pasted in Windows Explorer), to create a new solution; let's call this one Bravo. I changed the solution and project name and all associated filenames, then edited the content of Bravo significantly such that it appeared very different to Alpha when the application was run in a browser.
The strange behaviour is as follows. If I am working with Bravo in Visual Studio, and I run it in a browser, then everything appears as would be expected with Bravo. However, if I then load Alpha in Visual Studio, and then I run Bravo, then the website that is displayed is actually that represented by the code in Alpha, not Bravo. If I then close Visual Studio instance running Bravo, restart it, and then run the Bravo application, the website displayed is back to the expected version for Bravo.
So, it seems that there is still something remaining in Bravo that is referencing Alpha. If I load up Alpha, then something is being loaded into memory which overrides the data which Bravo provides during the application launch. Only when I restart Visual Studio and refresh this memory with Bravo, does it run with the updated version of Bravo, rather than the original version of Alpha.
Similarly, if I have Alpha loaded in Visual Studio, and then load the Bravo solution in another instance of Visual Studio, then run Alpha - it displays what I would expect to appear from Bravo.
Any ideas on what is causing this behaviour, or how I might investigate this further?
Thanks :)

Sergey is correct.
I have this happen all the time, when going back and forth between web solutions that I host in IIS, I always have to change the paths back and forth. This started with VS 2012 and continued in VS 2013.
I can't find much information on why it is happening or how to correct it. There are only work-arounds as far as I can tell.
Workaround and info on the bug request
another potential post on same subject.
I personally, just manually change it back and forth.

Related

What is the purpose of "building" a .NET MVC application if it runs fine without it?

I have a simple MVC Web application in the .NET Framework. To run it, I can click the green arrow ("play" button) in Visual Studio, which does a "build" and starts a Web browser pointing to the application.
Or, I can just start up IIS Express with the proper command line options, and navigate to localhost:8080 in a browser and run the application without a "build".
What is the purpose of "building" the application in Visual Studio if it runs fine without it?
The simple answer is that it doesn't run without the build step; your assumptions are wrong.
However, Visual Studio continuously monitors your source files and compiles them, e.g. to be able to show intellisense suggestions and compiler errors while you type. This means that there are in fact compiled binaries based on your source somewhere, maybe just not in the bin folder under your project root (that somewhere might be in memory, or in some cache location on disk, depending on circumstances out of scope for this question).
It's also very likely that you've previously built your application, resulting in binaries in your bin folder, even if you didn't do it with the purpose of running the application right after. In either case, if you get it working with IIS Express it's because it can find compiled binaries somewhere, and run those.
The main reason to have Visual Studio explicitly rebuild your app when you hit play, is to make sure that you're running the latest version of your code. Sure, it takes a few extra seconds every time you start the debugger, but it's nothing compared to the time you'd lose trying to track down a bug that you've already fixed in your code, but which still manifests in the running application, because the running application is an outdated version. (It also makes things like stepping through the code much less confusing, since, again, the source code on file will always be in sync with the running application.)

how to display an MVC View's path in visual studio

It is extremely common for my views to have similar names but vary only by their parent directory (which is the name of the controller). In other words, I use the default patterns handed to us by the benevolent MVC overlords.
I've always found it annoying to see 3 different tabs named List.cshtml, however. I would rather see Employee\List.cshtml, Product\List.cshtml, etc.
Somehow, today, I got this very desired result in Visual Studio, but I have no friggin idea how I did it. Opening any other view results in only showing the file name. So, how the hell can I do this regularly and consistently?
It doesn't have anything to do with the active tab. I'm using VS2013 Ultimate. I do not have Powertools or Web Essentials installed right now but would be willing to if it meant I could see the tab on the left all the time.
FWIW, I closed the Move.cshtml tab and when I opened it back up the path disappeared.
EDIT:
Well. I now remember what was different about that file... my computer crashed (BSOD) and Visual Studio asked me if I wanted to recover my changes to Move.cshtml. That has to be why it is there. I am disappoint.

How do you stop visual studio 2012 trimming white space on save

this is really giving me headaches, ever since I installed the last update pack, visual studio[2012] keeps removing white space at the end of each line when I save a file.
it's fine if I'm working on personal projects, but not when working on team projects where code changes are reviewed that gives reviewers hard time for so many changes made turn out to be white spaces
I can't find any settings that turns this off, there're some posts online mentioning about injecting a piece of macro in the IDE to stop this from happening. Seriously? I can't believe Microsoft delivers such a bad feature that there's no way to turn it off...
can anyone here help me out please?
please note it's Visual studio 2012

MVC View designer complains "There is no endpoint listening at net.pipe://localhost/

I recently installed Visual Studio 2012 (Ultimate edition) Update 2. I'm not sure if this problem is related to that update but.. now, when I view any of my View (.aspx) code in the VS designer, the initial #model or #using directive gets a squiggly underline and an associated error message of "There is no endpoint listening at net.pipe://localhost/xxx". All of the code in the page that relies on the #model or #using directive gets its own associated squiggly underline errors. But the code runs just fine. The error is in the designer, not in the runtime JIT compiler magic.
Any suggestions?
After a bit more digging, I found a blog post that suggested that the problem might be caused by failing to run VS as administrator. I tried that (I ran VS as administrator and loaded the offending solution) and, bada bing, bada boom, problem solved.
I've been happily skipping the "run as administrator" rigmarole for ASP.NET projects, and everything has worked correctly. I guess they must have changed something in Update 2 that now requires ASP.NET MVC projects to be opened with admin privs.
Can someone who knows better than I confirm this diagnosis?
(BTW, I ran across this post that shows how to force VS to always run with admin privs on Windows 8. This is an all-or-nothing solution... What I'd REALLY like is for the VS developers - or someone with time on their hands - to add a context menu item to .sln files to open them in VS with admin privs enabled.)
EDIT:
4 months after I posted this "solution" (actually, a work-around), here's where I am: I opened an incident with MSDN tech support. After much work, we got nowhere; still no clue what the underlying problem might be. But this problem only exists on my desktop PC - my laptop doesn't have the problem - and I'm buying a new PC, so the problem should go away when I install VS on the new PC and turn the old PC into a doorstop.

Tfs project have red x on it and can't expand to work items, source etc. on one machine

I have a user that is trying to access a team project that he has been working with (in).
He has 2 computers, on 1 he can access it, on the other he can't (project has red x). And actually he can access any projects on that machine, all have the same red X.
He was been able to accesses the project on both machines last week. And I have no idea what could have changed.
Searching the web found a # of post regarding folder within a project with a red X but not much on a project itself. But we tried these 2 links ...did not help
visualstudiomagazine
social.msdn.microsoft
Also tried re-installing Team Explorer & installed SP 1 (it was not on the machine).
Any ideas where to start looking?
Thanks
The 'Red X' problem can be from many different causes.
However, seeing as the user is experiencing the problem on one machine, and not on the other means that it's unlikely to be a server-side issue.
On the computer that is having the problem:
Close all instances of Visual Studio
Close any other applications that could be using the TFS Object Model
Open and delete the contents of the following folder: %localappdata%\microsoft\Team Foundation. On Win7, this will typically expand to something like C:\Users\<username>\AppData\Local\Microsoft\Team Foundation
Start Visual Studio again and connect to TFS
TFS clients have a local cache of metadata. There are situations where this metadata can get corrupted. Therefore, deleting it will force a fresh download of the metadata and resolve the Red X issue.
Enabling tracing on the client and/or TFS server should allow you to track down the error.
This happened to me after installing .NET 1.1, Visual Studio 2003, Active Reports 2.0 and Dundas Charts on 64-bit Win 7. None of the other fixes worked for me, but I resolved my issues (which also included weird IE behavior) after running the ie8-rereg.32-on-64.cmd script found here: http://iefaq.info/index.php?action=artikel&cat=42&id=133&artlang=en.

Resources