I have created a new project following this tutorial https://www.youtube.com/watch?v=ytDTkFJOJIE using aspnet core spa templates (angular to be specific).
So when I run "dotnet run" the first time it works fine, it runs the site as to be expected.
Now, when I commit a change, like delete the navbar and the references to it, the "main-server.js" and "main-client.js" don't update, nor does the site in the browser.
What am I doing wrong? If any more info is needed, let me know.
I was facing same issue. Below steps worked for me:
Delete all files from dist folder
run "ng build"
When the application runs, if you still don't see the changes, Empty cache and hard reload the chrome browser (hold browser refresh button for long, and select "Empty cache and hard reload")
It appears to be I had to set the environment variable. Although it might be set on launchSettings.json, you have to run this command
$Env:ASPNETCORE_ENVIRONMENT = "Development"
for it to work properly. Took me since yesterday to find this, hope it helps someone else.
For me the problem was Visual studio had checked in the .js and .js.map files for a few of my .ts components.
Visual Studio also checks in the main-client.js, vendor.js, and vendor.css files by default. Makes sure to either remove these from source control (recommended) or check them out before running.
In my case it failed to update because it was still running under IIS Express. I solved it by changing the profile from "IIS Express" to [project name] (both in the VS task bar and in the project properties under "Debug").
I too faced this problem while i executed my angular 7 with.net core app in IIS express in VS2017,
solved this by building the angular app(clientapp) in cmd by "ng build".
Then, close and reopen the application. so that VS loads the project again.
Now run the app using IIS express.
this worked for me. so give a try.
I have passed trought the same problem.
You have two options:
Delete the "dist" folder(this folder will be recreated everytime
you use 'ng-build')
Make the implementation equals the link below. This implementation
makes the application ignore the dist folder. It will only be used
at production environment.
Implementation
Related
I tried to automatically reload ASP.NET Core project as I do using Angular with Node or NPM.
When I change the code of the .NET Core project and save, I want the web page to be automatically refreshed in the web browser.
run this command in project console
dotnet watch run
same works for visual studio code
From Develop ASP.NET Core apps using a file watcher (for 3.0)
dotnet watch is a tool that runs a .NET Core CLI command when source
files change. For example, a file change can trigger compilation, test
execution, or deployment.
The link above contains a tutorial with two sample projects:
WebApp (an ASP.NET Core web API) and
WebAppTests (unit tests for the web API).
Alternatively, you can also this nuget package for runtime compilation.
I think that dotnet watch should work. See the documentation from the link as there are various options.
Add Microsoft.DotNet.Watcher.Tools to the tools section of the
project.json file
Run dotnet restore
Execute with dotnet watch run
You can use dotnet watch. Viz. Docs
I have created custom lunch profile to make it easyer to run in VS.
"Watch": {
"executablePath": "dotnet.exe",
"workingDirectory": "$(ProjectDir)",
"commandLineArgs": "watch run",
"launchBrowser": false,
"launchUrl": "http://localhost:5000/",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
According to this requirement, we need to run .net core application just like Angular application, loading the pages and contents automatically without built and manual refresh.
I had done some research and experienced that auto-reloading is not possible in ASP.NET core project. However, we have got the success, in our solution we are using dotnet watch which monitors source files and if a file changes, shuts down the application that it started, rebuilds and publishes the project, and then restarts the application then we just need to refresh page manually in the browser to get the changes which made in application, we don’t require to build or start the project.
Steps to follow to use asp.net watch:
1) Create.Net core application.
2) Open a command Window in your Web project's folder
3) Type dotnet watch run
4) Open your browser and navigate to an API or Page
5) Make a change to source code
6) Save the file
7) Go back to the browser and refresh manually
8) You should see the change reflected
Use dotnet watch to recompile the source code. Use Browser Link with "Browser reload on save" from Visual Studio to reload all your browsers. https://marketplace.visualstudio.com/items?itemName=MadsKristensen.BrowserReloadonSave
One of the tasks automatically created in VS Code environment for a ASP.NET Core project (web, mvc, etc.) is called "watch". To check this, from ".vscode" folder, open the file tasks.json and you will see 3 tasks configuration: "build", "publish" and "watch". By default, "build" is used in launch.json. You can then go in the "configurations" section of launch.json and look for "preLaunchTask", and there, you can change the task to "watch". And that's it. Hot reload will be active when you run your web application.
Regards.
You should think triple before going forward to this option. (1) It is a resource-consuming. As it necessitates auto-build, as pre-operation, of the modified project and sometimes the whole solution. (Imagine a medium to a huge Asp.net solution composed from many projects, get built for each modification performed !! how much time is left for programming ???!!) (2), as you know, the page reload consumes much time for the first launch after a successful build !!... Hence, the time you want to gain from this option you will be wasted multiple, especially CLR-based programming languages (e.g. .NET Core). And finally, (3) your project is expected to be in need to develop test samples that can be injected automatically in the view for a better automation process, imagine how difficult it is!
Instead, try to unit test your solution, and then, any next modification is expected to be superficial and low occurring.
If you disagree with my proposition, I suggest developing a visual-studio extension that better reload the target web page on-build rather than an on-save-changes event. Next, Ctrl + b will do the job!
Where to start?
I have developed a VSIX that watches folders to load automatically specific generated files outside the VS UI. check the source code you will have an idea about the project's files management. it revolves in the EnvDTE API, please have a look in this piece of code.
Also, check the source project from here
Follow the procedure indicated in the Microsoft's page.
Nuget package Microsoft. VisualStudio. Web. BrowserLink
Install NuGet Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
app.UseBrowserLink(); in the startup.cs page on the configure method.
and enter image description here
now when you change something on your code Ctrl + Maj + enter and everything is saved and actualized on your browser.
UPDATED
I refactored the entire question, because now, I Know what are happening, Thx to Daboul
When I start the ASP.Net Core exe inside the VS15 or even on a cmd line with dotnet run it's work fine, but when I try to double click on the exe to run, it's doesn't find the .cshtml.
The weird part, is that the files are there, and are found when executed by vs15
Can someone explain to me what I'm doing wrong?
I just create an Asp.net Core Web App and changed the project.json to produce the .exe like here and here
Visual Studio and dotnet run run your application in the folder where your code exist. It means it can access the Views folder and the .cshtml files you are editing when you are coding.
However when your run your .exe application, you do it from the publication folder, for exemple ...\Visual Studio 2015\Projects\MySolution\src\MyProject\bin\Debug\netcoreapp1.0\publish I would advice you to go to this folder and check that the folder Views exist. If it does not, it means you just need to publish your views by adding "**/*.cshtml" in your project.json:
"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml"
]
}
Then publish again with dotnet publish or your previous method. It should fix your problem.
Just for knowledge: It is now possible to precompile all the views with .NET Core 1.1. It means there would be no need to publish the .cshtml files.
You can see that one is running in development (the one working) while the other one is running in production. You should first try to remove this difference, see if it fixes the issue. I use a MYEXE_DEV.bat file to do that:
setlocal
set ASPNETCORE_ENVIRONMENT=development
yourbinary.exe
endlocal
Give it a try.
UPDATE:
Ok, let's try to move forward a bit then. When you launch you app by pressing F5 in Visual Studio, VS usually (it might depend on your template I guess) uses a launchSettings.json file with several launch profile, for instance below I have two predefines profiles IISExpress and WebApplication1, and in the .json file you might have parameters that explain why it's working under VS, but not when just double clicking on the exe.
When using Visual Studio 2008, when I "Publish Web Site", the application builds correctly, but then I get a "Publish failed" message:
What possible reasons are there for this, and how can I prevent it?
I had the same issue. Nightmare to identify the problem, because the logs and outputs show no errors or failures. I simply get "Build: 39 succeeded" and "Publish: 1 failed".
I resolved the problem by systematically removing all NuGet packages one at a time (and removing code that references it) until I identified the offending one.
This takes a LONG time!
However, the answer for me was Microsoft.Net.Compilers.
No idea how I ended up with that in my project, but as soon as I removed that package, everything publishes fine again.
Edit - For what it's worth, this problem occurs on VS 2008, 2012 and 2015 but does not occur on 2017.
You can try this:
Perform precompilation against the web application.
Clear the target directory(virtual directory in IIS or physical file
folder) and deploy all the files (of the web application) into the target
directory.
In the output window you can check at which stage does the publish website
operation fail. For example, at the first stage, if there are some error
which will only occur at precompilation, that will cause the stage 1 fail.
Or some times if the target directory has something configured incorrectly.
Such as the IIS virtual dir is not set to the correct ASP.NET version or
some old files are locked and prevent them from being cleared. Mostly,
publish failed will be caused by IIS side configuration issue such as
authentication setting....
Source link
You can open the output window by pressing Ctrl+W, O.
Sometimes it's because you need to be running VS as Administrator to be able to write to the target directory.
Check the Output messages, they should help you solve the problem
I had to copy project to C:\a\ and than publish. I suspect problems with long path. Strange, but worked for me.
The conclusion is: Try another VS edition and see if that does it.
Here is what did it for me.
I have VS 2013 Pro and Visual Studio 2015 Community. I sort of use one or another to work on my MVC project and all was fine. Then all of the sudden VS 2013 could not publish though it would build just fine. There was no erros other than some silly ...code is not returned from all paths...
So when I open it in VS 2017 - it published the same project just fine. I am suspecting a compiling issue - because that was the stage it would fail at.
Hope that helps you save a bit of time.
Not sure if this happens in different versions of Visual Studio, but at least in 2015 Professional Edition, the problem arises when we try to update all Nuget packages from the solution using the Packages Manager.
As pointed out by #SimonGoldstone the issue is caused by the package "Microsoft.Net.Compilers". By default, the package gets added to the solution while creating a new web application. The default version 1.0.0 does not introduce any problems. I was able to keep testing with latest versions until 2.4.0 and everything works fine, but from 2.6.0 henceforth is when it all starts. If an update is strictly required, I would recommend updating the aforementioned package until version 2.4.0. After doing some research, seems that some bugs on later versions than 2.4.0 are introduced and not fixed on the long term. What is curious though, is how this problem gets included on Nuget with no basic quality control checkpoint.
There are many proposed solutions for this. I think they are overcomplicating the issue.
I found the following worked for me:
Locate the obj(Release or Debug) folder in your solution
Inside the Release or Debug folder delete the CONTENTS of the 'AspnetCompileMerge' folder
Now try and publish.
Make sure you empty the target folder (manually) before publishing. Sometimes vs cant delete a file which will result in a failed publish
After trying a Rebuild, having other Projects in my Solution able to publish correctly, and changing my publish location to the C: drive (locally attached) instead of pushing to a mapped network drive, I was still having an issue where the only error output said:
========== Build: 5 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
My solution is targeting x86, but I think during a Git Merge, this project had it's profile switched to Any CPU. After creating an x86 profile for the project and having it match the target of the publish goal and of the active solution configuration, I was able to successfully publish again.
Check Project BIn directory. there must be a DLL of your page or control. which has to be recreated during publish. So exclude it or remove it
I ran into this same problem today and it was due to the Thumbs.db file that was created when I opened my images folder to look for an image. I deleted the file and the project deployed successfully. Hope this helps someone else in the same situation.
Delete publish profile and create another one . Worked for me
In my case, I was publishing to a directory in a mapped network drive, but the Output panel/window was indicating that the location didn't exist. The path was correct, and the drive was fully accessible. The problem resolved itself when I re-set the path to publish to in Visual Studio by using the ... button.
With me it was simple - the dist folder was locked. I unlocked it by an unlocker and the publishing resumed.
I have several user controls that are registered in the web.config, and have a ClassName in the .ascx file header. For normal builds everything works fine, but with a publish those class names were not recognized anymore. At some point I found out that the errors were not in my regular code files, but in copies in a temp directory for publishing.
I had "Precompile during publishing" turned on (to be found under Settings > File Publish Options). Turning that option off worked for me.
I had the same issue with VS2017 with a website project. Build worked, but publish gave me an error:
Error CS0012: The type 'System.Net.Http.HttpMessageHandler' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
All my projects already had a reference to System.Net.Http so it was really confusing.
To fix it, I had to copy System.Net.Http.dll into my website project / bin folder so publish could find it and copy it to my web host. I found System.Net.Http.dll by looking at another project's references (a class library), then System.Net.Http.dll Properties, and seeing the path (C:\Program Files(x86)\Reference Assemblies\Microsoft\Framework.NetFramework\v4.6\System.Net.Http.dll).
i know iam late but i think it should use for someone whos searching for this query.
just uninstall all your nuget pakages , then clean and rebuilt solution ,
now click on publish , sure it works and u will see publishing starts and works correctly now
If any one had changed the version of the project file and related framework. then this type of issue happened.
please go to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0\Web" location for visual studio published and build setting -> edit -> comment the force copy of all file section.
I had one file that was not found. I had copied in a png file to replace a jpg in the content folder , same name except filetype extension.
Project built fine, but refused to build and publish . changed extension of file so it could find that file name and it worked - no errors amazing 1 thing wrong and everything else is an error.
The case for me was that Visual Studio was not signed in to Azure, but provided no indication of that. I edited the publish profile, clicked "Validate Connection" then clicked "Save" and then it worked.
I was working on a feature branch, which was failing. Switched to Master Branch, deleted the feature one and created another one. It worked.
What caused my issue was a little different, but has similarities to some of the reasons stated above.
I managed to trash my local copy of a given application and did a GIT hard reset to get the most recent from the repository in question. This in turn, wiped out the web.config file (which was not stored in the GIT repository for various reasons).
This cause configuration information for various NuGet packages to be "lost" (since it was stored in web.config).
Fortunately, I had "backed up" the web.config, so once I figured out it was not out there (a migration failed because I was unable to connect to the database), I was able to replace it.
Tried the publish again, after fixing the web.config, and everything worked perfectly.
If you are opting for the "Delete all existing files prior to publish" in the publish web dialog box, then make sure that the Visual Studio is started with Admin rights. Right click the Visual Studio and click Run as Administrator. Hope this helps.
For one of the solutions, I don't see the Clean Solution option neither in the context menu when I right click on the solution name in the Solution Explorer nor in the Build menu. When I make any changes to the project and debug, VS never hits the break point and I get the "The breakpoint will not currently be hit. The source code is different from the original version." message. My understanding is that I need to clean the solution.
For other solutions, I do see the Clean solution and I don't have the same issue.
If you are using website project then their wont be clean solution option,it's available only with web application projects.
Finally had to create a brand new solution and add the projects from the older solution to the newly created one. Not sure what the problem was, but this helped.
I also faced the similar problem recently and this is what I came to.
I guess you are running an older code version than the one you want to debug on. Rebuild the project(s), paying attention to dependencies. Use the "Rebuild" feature.
If it's a Web application project, just clean it yourself by nuking all DLLs in the bin. Then rebuild. I assume it builds without errors?
If you're running a web site, as apposed to a web application project, you probably don't have an actual solution, or even a project file.
For a web site, you need to rebuild the website (from the build menu), or manually delete all of the dlls to accomplish the same thing.
Edit:
How are you debugging? Are you using Cassini (the built in visual studio debugger), or attaching to an IIS process?
I would also try this:
Go to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files and delete the folder that has the same name as your website.
I had the same problem. Visual Studio was building my old code with debug. I opened a new instance of Visual Studio and opened my solution with it and it now works fine. No idea what happened.
You can also clean using devenv /clean SolnConfigName SolutionName in the command line environment.
Here is the reference: http://msdn.microsoft.com/en-us/vstudio/aa718635.aspx
For a website solution, just clean your web browser history and the Cache there.
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>