I have a visual studio 2010 web project that when I publish it in debug mode the application works fine and is the latest build.
However, when I try to click the play button/debug mode (in the same build configuration as what I published in) the assembly version is older than the most current one. As mentioned, this is a asp.net application using a c# class library as a reference (also in the solution) and I am debugging using Visual Studio's built-in web server.
I've tried everything I could think of at first in all different combinations as follows:
Clean solution
Clean each individual project
Build solution
Build each individual project
Rebuild solution
Rebuild each individual project
I tried to use a different browser and cleaned my cache as well.
Has this happened to anyone? How can I correct this issue?
It is most likely not set to build. To test this, try build then debug and see if things work. If so, then it is definitely not set to build.
To solve this, open up the Solution Properties. Go to Configuration Properties >> Configuration. Then run down to the project in question and check the Build checkbox. You will then be able to debug again.
This one bit me when a coworker decided the build of the UI was taking too long for his testing and removed it from the build. After discovering the issue, I had him create a separate solution to test in isolation. Yes, multiple solutions can contain the same project(s).
did you try deleting your bin and obj folders and removing your assemblies from the GAC? I would guess that THIS is the problem.
Don't forget to clean your Temporary ASP.Net (c:\WINDOWS\Microsoft.NET\Framework[version]\Temporary ASP.NET Files) files.
After that, do a rebuild and try.
Also, for local development, if you can, then do not GAC assemblies. GAC them while deploying to integration environment. THis will help speed up development a bit.
Related
I am using Visual Studio 2017 Enterprise, C# 4.7.2
My Solution contains currently nine different projects. A build succeeds without any error messages. When I run the application, a TypeLaodException is thrown, The Type Namespace.AClassName could not be loaded.
The weird thing is, that there isn't any class named AClassName anymore. BUT, the mentioned class did exist in a former version.
I cleaned the solution, startet a build, same error. I rebuilt the solution, same error. Cleaned than rebuilt the solution, same error.
Apparently, the build is not correct. But what can I do to ensure, that the build runs correctly?
If manually deleting the folders bin and obj as suggested in the comments is not working, I will also delete de .vs and there are a few things you can try:
Unload the projects, and search in the .csproj for any reference to
the Old-Deleted AClassName. Check also that there is no namespace related to it. You will have to do it in the project where originally was the class, but I will recommend to search in all 9 projects.
Check if there is any Project Dependency in the Configuration Manager related to the project where the AClassName was.
I would also restart my machine, delete temp folder and run VS As administrator.
Clean Solution.
Clean Debug & Bin folder.
Make sure all project reference are from Project libraries (it should not be directly from Bin folder).
Make sure all interconnected project build on same .net platform (4 , 4.5 or 4.6 ).
Build and try to run.
the problem is thus. Every time I open a specific solution in visual studio it hangs forever, you get the annoying Visual Studio is Busy popup. The only way to get it to load is starting visual studio in safemode or by deleting the v12.suo file before opening the solution.
Once it's hung all the projects are marked (Initializing) apart from one project that is (loading). This project is from a different solution and from a different place in the tfs tree. If I unload the shared project then VS loads the solution fine, I think the problem is with TFS, can it deal with a project in multiple solutions?
Thanks
You should remove the shared solution and instead share discreet components as Nuget Packages.
I would generally have a Solution & Project for each of my shared groups... Usually there is a relationship between the css, images, and JavaScript... And package each one as a Nuget Package. Add an automated release pipeline and you can have checkin->dependancy in very short order.
I use VSTS and have a Build that creates a Nuget package with the bits I need and then use the release management tools to control visibility and quality of that package. It's then easy to have your packages deployed to a Nuget Repository (I use VSTS) and let any of your internal projects take a dependancy on them.
This will have the added bonus of increasing quality and knowledge of dependancies and interfaces in your devs. Let them have a dumping ground and they will always use one.
You can do below steps to narrow down this issue:
Try invoking Visual Studio from the command line devenv.exe /log. Then try to open your solution and then if it crashes, go look at the
%APPDATA%\Microsoft\VisualStudio\<version>\ActivityLog.xml
file. It will including some details on the crash. Also, the event logs may capture some high level events as well.
I have a big solution with 30 projects of which 2 are web projects (MVC and WebAPI) with a bunch of background class library projects.
I have visual studio set up to host the web projects in IIS.
If I do a clean build, followed by a full build of the entire solution, then accessing both projects via a browser works fine. (they are in diff folders and hosted on diff 'domains' in iis)
If I make NO code changes, simply rebuild one of the 2 web projects, the OTHER one stops working.
To be clear, rebuilding the WebAPI project causes the MVC project to have errors. And vice versa.
The error I get is saying that System.Web.Http.Formatter is not found. The detail says that the located assembly version is different from the reference version. Checking the bin folder shows that that is not the case.
Make sure that all the solution's resources are up to date. If you use Nuget, update all packages in all projects (back up first!). It sounds like you have a version mismatch, where functionality is missing in DLLs copied to the output directory for the solution. It may involve changing some entries in the Web.config of each project, but without access to the code, it's hard to know for sure.
Report back once you've updated every library, and made sure the versions match across all projects in the solution.
In addition to Apache's and Steve's suggestions, I'd also recommend deleting the files in your Temporary ASP.NET Files directory. If you're curious here's a good write-up of what the contents of that folder are for.
I have a Visual Studio solution (C#) which represents the core of our application. We build this and it comprises about 10 or so DLLs with corresponding PDBs.
I have several other VS solutions each of which is used for a customer of ours. These VS solutions use the core DLLs and add their own bits as required. The "core" has the main .exe so we do the following in customer specific solution
Post build step in the a project to copy the EXE/DLLs/PDBs into the $(TargetDir)
Set project debug settings to "Start External Program" pointing to the .exe
This all works, tho seems a bit clumsy.
My questions are:
When running via the customer specific solution, how can I
Have the code for the core project open automatically when I step into it
Be able to open a core file and set a breakpoint
I'm used to Java where you reference the compiled and source jars/directories from the Java IDE and that's pretty much it. How can do the same in visual studio (DLLs and PDBs)?
(I would prefer to avoid the GAC if possible because we sometimes have several local builds of the core around at the same time working on different projects)
Mike, if you open an "higher in stack" solution which references a core solution, you can open the source file of the core solution and put a breakpoint in it, then when you debug the current solution Visual Studio is smart enough to step into and trigger your breakpoint if the .pdb files are available in the bin folder.
TO automatically have the debugging control traverse into the core source files, make sure to refer the core dlls from locally build core solution and make sure that have access to it.
Another way is after having the core dlls refered, just open the CS file in which you want to put a break point and debug.
I am building an application which is based on a sample application,
written in C# on .NET 2, and is built on VS2008. This application is mostly a wrapper for a COM application.
However I compile it in .NET 3.5.
The sample application came with the following files in it's bin\debug:
appName.vshost.exe
appName.vshost.exe.manifest
I noticed that I can delete the files and VS re-builds vshost.exe, and the vshost.manifest file appears with modification date the same as the deleted file as if VS has copied in from somewhere.
My question is, should I put this files in my SVN code repository?
Those two files you list implement the Visual Studio "hosting process". It is a hosted version of the CLR, designed to improve the debugging experience. It takes care of some security issues, the most visible side-effect is that it redirects output written with Console.WriteLine() in a GUI app to the Output window.
These files are not part of your project and do not get deleted when you use Build + Clean. In fact, you cannot delete the .exe file, it is always running while you've got the project opened in Visual Studio. You can disable the hosting process feature with Project + Properties, Debug, scroll down, "Enable the Visual Studio Hosting process" tick. There's no compelling reason to do so.
There's no need to check these in, Visual Studio re-generates them when you check-in a project and load it in VS. In general, you never need to check anything in from the bin subdirectory, its content is always re-created by building your project.
Everything in the debug (or release) folder is generated. Everything that's generated shouldn't be checked in.
When in doubt, just make a fresh checkout to some other folder (or even machine), and try to build from that. If something is missing, this will find it.
I do not think you should. They are for VS use only.
Here are the files I ignore when creating C# projects. You really only want to store the source code in the repository and not the outputs. Similarly you probably do not want to store the user based information that goes along with VS solutions.
*.csproj.user
*.suo
bin (folder)
obj (folder)