Current project:
DotNet 4.7.1
MVC 5
Database-first from a legacy DB, [DbName].edmx file in /Models/
When trying to build the project in order to test it, I am getting a sudden error (CS1566) that there was an error reading the resource Models.[DbName].csdl, and it could not find part of the path. Sure enough, the entire \edmxResourcesToEmbed\Models\ folder was missing from the \obj\Debug\ directory.
How do I rebuild this? This is my first database-first project, everything else has been code-first, and Google is bringing me back nothing.
Thanks to StackOverflow’s ability to link in other posts you would normally not think were related, I was able to solve this problem.
This issue also came about because of code-first workflows that I had adopted that I needed in order to prevent errors under code first using multi-project repository patterns. Specifically, I modified my *.csproj files to always delete the bin and obj directories of the project(s) that I build/publish:
<Target Name="BeforeBuild">
<!-- Remove obj folder -->
<RemoveDir Directories="$(BaseIntermediateOutputPath)" />
<!-- Remove bin folder -->
<RemoveDir Directories="$(BaseOutputPath)" />
</Target>
Why? Because when I didn’t, any attempt to build/publish a code-first project would fail due to “multiple, conflicting web.config files”. Which I don’t have in the first place, but that’s what it complains about. So by habit, I just engineer each project to delete those two directories before building/publishing, so as to avoid that show-stopping error.
Essentially: the system was giving itself a fatal haircut every time it went to build or publish, by clearing out a bin file that was needed by the publish process. All thanks to me and code-first multi-project repository pattern solutions applied to a database-first project. Sweet. facepalm bridgepinch smh
And when I first made this post, I got one Related link shortly after posting. The first half of that reply made sense - select the *.edmx file and change the Build Action value, but the second half confused me until I actually opened up the *.edmx file and clicked on an empty part of the model diagram that came up -- suddenly, my properties sidebar changed to something completely different, which did have the Metadata Artifact Processing value that needed changing.
By following those instructions, then shutting down VS, then removing my *.csproj modifications, then opening the project back up, then building, then reversing those instructions and actually publishing, I was able to reverse the damage I had inadvertently done.
So, FYI for anyone else who has the same problem.
I have a web application in VS 2017 for which I've defined a publish profile which works, happily, deploying / publishing the website to a location on the file system.
I understood that this was possible as part of the regular build process, i.e. just building the solution in Visual Studio or TFS build - and that this was achievable with a section like this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<DeployOnBuild>True</DeployOnBuild>
<PublishProfile>ProfileName</PublishProfile>
</PropertyGroup>
However, this has no effect whatsoever, the build output log just shows the regular build happening and no attempt to publish.
Should this work as suggested in various answers on here and MSDN - and if so, what is wrong with the above?
(In case anybody is wondering, the reason for doing this is that a single solution being built by TFS cannot separately publish > 1 web application with separate publish profiles as required with the build definition MSBuildArguments setting).
I want to credit #Andy-MSFT who posted a very close answer, but in the end there were some vital details missing and some corrections required to make it work.
First off, the working solution was:
<Target Name="Deploy" AfterTargets="Build">
<MSBuild
Condition="'$(DeployOnBuild)'!='true' And '$(Configuration)|$(Platform)' == 'Release|AnyCPU'"
Projects="$(ProjectPath)"
Targets="WebPublish"
Properties="DeployOnBuild=true;PublishProfile=FolderProfile"/>
</Target>
The WebPublish target will only work on a TFS build server if the "Web Developer Tools" of Visual Studio (2017 in my case, as per the question) are installed. Note that the "Projects" attribute had to be set with $(ProjectPath) which is also different to Andy's answer and was also needed for this to work.
The DeployOnBuild property specifically was ignored when set statically in the project file. Apparently it is a special property that must be set globally on the commandline.
As a workaround, you could call MSBuild again to pass the property. See How to: Extend the Visual Studio Build Process
Open the .csproj file with text editor.
Add below snippet at the end, then save it.
<Target Name="AfterBuild">
<MSBuild Condition="'$(DeployOnBuild)'!='true'" Projects="$(MSBuildProjectFullPath)" Properties="DeployOnBuild=true;PublishProfile=YourPublishProfile;BuildingInsideVisualStudio=False"/>
</Target>
Below threads for your reference:
Publish WebDeploy Automatically with VS Build
Visual Studio 2013 Build and Publish
I'm trying to set up Jenkins with MSBuild plugin. I got Jenkins to check out solution from repository and run a build. But every build fails with several
error CS0433: The type 'CustomControls_WarningPopup' exists in both (...)
WarningPopup is an .ascx defined twice - once per web site project, and there are two website projects in the solution. The thing is this never rises any problems when compiling whole solution from VS2010. Should I run MSBuild with some specific parameters to make it behaving like VS?
I already tried moving Temporary ASP.NET files to custom folder (like in this answer) and it didn't help. Probably I'm missing something obvious to CI experts here...
I found the cause. There was another UserControl in second project which accidentally inherited class of the same name. Both controls were in the same directory and nor Visual Studio during compilation nor ReSharper saw anything wrong with this. Moreover MSBuild threw errors in both Web Projects despite the duplicated control was in only one of them. The funniest part is that this situation was like this for months and never rised any problems...
Anyway changing class of this control solved the issue and finally automated build succeeded!
I used to be able to attach to my w3wp process and Debug my web application, but this is not working anymore. I have no idea what changed to break this. I'm using Visual Studio 2008 SP1. And I'm debugging in IIS, not using ASP.NET's own server (i.e. I don't Run my project, I simply attach to a running process (w3wp).
My breakpoints simply have the "breakpoint will currently not be hit. The source code is different from the original version."
What I have tried:
Did a solution Clean.
Did a solution Rebuild.
Made sure that compilation debug=true in my web.config file.
Deleted the bin folder
Restarted Visual Studio
Restarted IIS
Restarted my Computer
Added a simple Response.Write to ensure that the latest DLL is being used. It is.
Made sure that Debug ASP.NET is checked in my project properties. It is.
Made sure that all my projects are compiled in my build configuration. They are.
But none of these help. I attach to w3wp, but my breakpoints never get hit.
Any ideas?
I had this problem recently and I ended up first making sure Visual Studio was not running at all on the system.
Then went into this folder and deleted all its content:
C:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\
Check your web.config for
<compilation debug="true">...
When you "Attach to process", the Output window should show you (when showing output from "Debug") all the libraries it's loading, and where it's loading them from - for the dll's in your /bin folder these are usually copied to the \Temporary ASP.NET Files\root\ folder - where are yours being read from? Have you definitely cleared them out from there?
The only other things I can think of:
You've compiled your code in "Release" mode rather than "Debug" (not the web.config) from the Solution Configuration drop-down.
The symbol files (.pdb) are missing from your /bin folder.
On the "Build" tab of the project properties, you are in configuration "Active (Debug)", you haven't check "optimize code"?
If you click "Advanced..." on that tab, what value do you have for "Debug Info"? Is it "full" or "none"?
Responding to comment
You will find it harder to debug successfully if your code compiled in "Release" mode, and you'll often get the "source code is different" message when you've not rebuilt the symbols (.pdb files) after changes - but you say you've done a clean/rebuild, so that should cover that.
Yes, your output window will show all the framework dlls that you're referencing as well as your code - but you should see one file listed in there with the name of each project output - those are the ones to look at.
You don't have some post build event that moves files into the correct directory for your site do you that's silently failing?
I also had this problem, solved it by changing the "Attach to" code type to Automatic on the "Attach To Process" dialog. (Previously I had this set to "Silverlight Code" due to debugging a different process... it can be easy to forget to change this back.)
I know this issue has been open for some time, but I think it is the same as I experienced:
I could not debug my .aspx server side code. I had a working WepApp AnyCPU project and I wanted to link to some x86 dlls, so I created an x86 debug target. Did similar things, rebuilt, stopped the development web server, rebooted, clear temporary files, all to no avail.
Fixed the problem by changing the target folder to bin\ (was bin\x86\Debug).
Are you running any add ins that could be affecting this? Or any tools that apply post build operations to the source code that the DLLs you start debugging with have been modified post build and it actually is correct that it's not the same source code so debugging won't work?
Also have tried resetting VS?
devenv.exe /resetsettings
Edit: if none of the information has aided you here, while painful it might be worth uninstalling and reinstalling VS and SP1. If you go through this and the issue is the same afterwards that atleast assures that the issue lies in either the web.config or the project settings.
Did you check your assembly.cs file with this attribute
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]
After reflecting a optimized code you will probably get this. So you must remove this to be able to debug again.
I faced the same issue. The w3wp process took a lot of memory and did not want to be reset on web application publishing.
Press Ctrl+Alt+Delete > Go to "Processes" tab > find w3wp process and
kill it. Run the app again (if this is an mvc app, just go to a
related url to automatically recreate w3wp process).
Warnings will disappear after that.
I have tried all the below options in my Visual Studio 2013 Update 4.
Reset IIS
Clean solution and rebuild
Delete the friles from temporary folder
C:\Windows\Microsoft.Net\Framework...\Temporary ASP.NET files
Check whether the compilation tag is debug or not
But none of them worked, here I am listing down the two things which worked for me.
Disabling the "Just My Code" option
Tools ->Options -> Debugging -> General -> Uncheck Enable Just My Code.
Edit the web.config file and save (You can always create a space in any line
in web.config, that will do)
Please be noted that this solution can be Visual Studio version specific, and the both fix worked for me in my Visual Studio 2013 Update 4.
in the "Attach to process" dialog, click the checkbox (near the bottom) for "show processes from all users" and if you see two w3wp.exe processes, try the other one.
One should have a comments/description value of something like T-SQL, managed somethingoranother. This is the one you want.
I have had this problem for a while and found my solution on the MS forum (link below).
Debug Diagnostic Tool was the culprit for me, but I did not have to uninstall it. I had a crash rule set up for the w3wp process and I simply removed that rule and restarted everything.
Microsoft Forum for Unable to attach error
On OpenVMS we just used to:
Compile/Debug then Link/Debug
and that was it! Simples!!
but seriously, make sure the file you have your Debugger.Break line in, has 'Copy always' set in its Properties before re-building
I was using the Visual Studio extension VSCommands to attach the debugger (convenient). However, IIS Express was running, and I guessed it might be interfering. Sure enough, when I closed IIS Express, suddenly I was able to debug again.
Joy ensued.
In my case I had a Console Application the hosted web page in .Net Framework 4.6.1. When I added a Debug to Conditional compilation symbols, it started to work:
Make sure that "Current Page" and not "Don't open a page. Wait for a request from an external application." is checked under Properties->Web->Start Action.
add this code in your .csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
<DefineConstants>DEBUG;TRACE</DefineConstants>
<Optimize>false</Optimize>
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
I have switched to a new PC and got the latest version out of source safe but now when I do a ReBuild I get Could not load type then the name of my namespace.the name of my pages?
It seems ok if I do a Build.
Any ideas?
UPDATE: Once a Rebuild is done it removes the Namespace.dll and then doing a Build it fails with the same errors.
UPDATE 2: I think it has something to do with aspnet_compiler.exe? Do standard Web Applications run this after a build? I have setup another test Web Application and it runs Csc.exe but not aspnet_compiler.exe but I can't see anywhere in my project where its configured to run this.
maybe you have refferenced a DLL directly, instead of a project in a solution.
This could cause a rebuild to work
I've lost references before when I've moved to a new machine. So, I would start by checking the references on the projects with the errors.
I found in my csproj file the following:
<AspNetCompiler PhysicalPath="C:\Projects\MyProject" Debug="false" VirtualPath="/MyProject" />
Not sure what this is doing, I think it was put in there for some reason.