I'm developing an asp.net application atm and it will be used to insert some data in a database.
Yesterday, I noticed that I've written the wrong table name in one of my insert statements. Ofc I changed it then, but..!
After getting the same "Unknown Column" exception again and again, I opened the SQL Profiler today and looked at the statement. The statement still tries to insert into the wrong table, but not in the "new" right one, which I've actually written in the code.
Why is the application not noticing changes? I tried to load the website without cache by hitting STRG+F5 for like 125392 times. I also deleted the cache folder, also without success.
Thanks in advance!
Edit: U may want to know that this application is running on a server. Therefore I need to edit the .cs-Files with Notepad because there is no Visual Studio installed on this server.
Are you sure this is running as a website project and not a web application?
If it's running as a website project then editing the .cs files should be picked up. The quickest way to check this would be to introduce a deliberate syntax error to prevent a class from compiling.
Web application projects are compiled before deployment. If there's a .cs file in the web folder for that then it's been deployed by a quick copy-paste rather than a proper publish from Visual Studio and, while the site should work just fine, changes to the .cs files will be ignored. As that's a compiled project you'd need to make the changes somewhere that has access to a compiler (ideally VS on your usual dev machine but I think you could use the command line compiler), then deploy those changes - ideally via a publish to leave the project in a clearer state for the next maintainer :-) If you have to do it manually for whatever reason though, remember you need the .aspx/.ashx etc or .cshtml / .vhbtml files and the DLLs.
.cs files need to be compiled for changes to be added to running library. It is not recommended to edit files directly on the server.
Related
I've searched and come across similar topics, but they all relate to ASP.NET core projects.
I have a traditional ASP.NET MVC web app using the .NET 4.6.2 framework.
When I run this project without debugging (CTRL + F5) I am able to see all changes made to html, js, and css files by simply refreshing my browser.
However, if I make a code change to a .cs file and refresh the browser the change is not shown. It obviously needs to be recompiled - if I then manually build the project, and then refresh the browser the latest change made to the .cs file is then visible.
Is there anyway I can make VS/IISExpress detect a code change, which then will automatically force the app to rebuild?
Here is an example of what I would like:
https://youtu.be/yyBijyCI5Sk?t=880
^ He modifies code (c#), saves the file, jumps back to his browser, hits refresh which then forces a recompile for a few seconds and then reveals the changes.
The project in this video is using ASP.NET core, so I guess automatic compilation is a feature of it.
Any ideas how to achieve similar for non-core asp.net projects?
Thanks
I dont know of any way to let browser force VS to rebuild project, however based on video. You could use something like link.
It is an extension which rebuilds your poject on save. So all .cs changes will be visible after save(build).
I dont personaly use it, just know it exists
Hope it helps.
Clear visual studio cache. step3 working fine for me.
Step 1: clear the Component Cache
Close Visual Studio (ensure devenv.exe is not present in the Task Manager)
Delete the %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache directory
Restart Visual Studio.
Step 2: cleanup your user’s temp folder
Delete the %USERPROFILE%\AppData\Local\Temp directory.
If all the above fails. you can try the hard route.
Step 3: delete the contents from the following folders
%USERPROFILE%\AppData\Local\Microsoft\Team Foundation
%USERPROFILE%\AppData\Local\Microsoft\VisualStudio
%USERPROFILE%\AppData\Local\Microsoft\VSCommon
I'm having a problem with a web application where the events in the global.asax class aren't being executed when I build the application through our build server and publish the website. In Application_Start is a single line of code sets up our logging, and in Application_Error I have some error handling code. Locally it all works fine, and if I copy the files directly from my development folder to the server rather than publishing it via the build server everything works fine.
From loads of Googling it would appear that this is a problem with the precompiledapp.config file being missing - sure enough it doesn't exist anywhere. However, nowhere can I find out how I actually get the TFS Build Server, or Visual Studio (2010), to create this file so that I can publish it.
Any advice on how I can generate this file would be much appreciated.
EDIT: A bit more information. I've just tried publishing the website through Visual Studio 2010 rather than the build server and this created the precompiledapp.config file. I copied all the files across to the server (except web.config which I left intact) and it logs successfully (which suggests the global.ascx events are being fired). What I need to do now is try and get the build server to do the same thing - any ideas?
Make sure your custom config file is set as a content file and Copy To Output is set to Always in the config file properties in Visual Studio.
I seem to have resolved this issue now.
As I mentioned in the Edit of my original message, when I published the website through Visual Studio 2010 to a local folder it created the Precompiledapp.config file, and copying the folder contents to the test version of the application got everything working. As I can't seem to get the TFS Build server to create this file, I decided to try just copying the file from my local publish folder to the test application, along with the rest of the files from the tfs build, and everything seems to be working as it should.
So although I've not managed to figure out how to get the build server to generate this file, my main issue is resolved and I'm able to use the global.asax file again.
I'm late to this question BUT you should probably verify that you have the correct SDK that visual studio would use to build the precompiled app (I think it's Azure SDK even if not doing anything with Azure but not 100% on that).
If you have visual studio installed on the build server you can just install the web workload (opening the solution will prompt it). I did this with Visual Studio 2019 today. MSBuild was ignoring not only my *.pubxml settings but even passed in properties via command line arguments to msbuild.exe (which overwrite the ones in the *.pubxml file).
I opened Visual Studio, it prompted me to install the necessary workload and I did. Everything started working as expected after that.
To precompile, in your pubxml file make sure to have this:
<PrecompileBeforePublish>True</PrecompileBeforePublish>
Also, this post refers to your Edit comment about how to get the build server to do it when it works on your machine.
I took over a web application project that reference dlls. The solution has the actual project as well as the class libraries used to create the DLL. I need to make changes to the web application and deploy to production. I'm use to deploying asp.net website as well as classic asp which was very straight forward, Just copy the files.
I need help to understand the compilation and deployment process. Here is some questions:
1) Class library(DLL) changed; do I just compile that class library project and move the Dll only.
2) Web application project changed and the dll stayed the same; what files do I move.
Also, if someone can clarify how DLLs version are handled when deployed. I'm use to the old way of unregistering /registering the DLLs and this is not the case right now. I'm worried about having multiple copies of the DLL on the same box.
Any help or reading reference would be appreciated.
Jamal
When you are manually deploying in that fashion it is very easy to make a mistake (forget to copy a related file). It's happened to me before.
I recommend that you make use of the publish feature in Visual Studio.
You can right click on the web app and from the context menu select 'Publish'. I normally publish to a local folder (You could publish to your server directly) and then use an FTP client such as FileZilla to actually deploy ( I've had some issues deploying directly from Visual Studio).
When you upload using FileZilla you can specify how you wish to handle existing file overwrites.
I use the option: 'Overwrite if source file newer'. That way deployment is fast (only the files that have changed are depoyed) and safe as we cannot miss a file.
To answer your questions:
1) yes, it is sufficient to deploy the class library but only if it remains binary compatible with the old one (Easy to make mistakes here).
2) You need to deploy the files that changed (dll's, aspx, cshtml, etc...). If the class library dll's have not changed you do not need to redeploy them.
Follow the steps above and you should be fine.
It sounds like you're talking about a precompiled .net application. The app is compiled using Aspnet_compiler.exe, and the new DLLs are copied to the host.
The DLLs don't have to be registered, IIS "knows" what to do with a precompiled .net app. It's pretty much just drop-and-go; not unlike copying the .aspx files directly.
You are able to update a subset of the DLLs (e.g., the class library). There are several modes available that allow you to compile all or part of the application.
When you change a DLL, often times you can just drop it right in assuming you aren't referencing by a specific version number. Generally to be on the safe side, I copy the entire website out again when changing DLLs. Its not strictly necessary, but its probably the easiest method if your website isn't too large.
If you're changing a file that is not deployed in its compiled form (.aspx, .aspx.cs, .cs files in the App_Code folder) you can just update that specific file and restart IIS for good measure.
Generally speaking, if a dependent assembly changed you can just deploy the new assembly. However, if ANY of the interfaces to that assembly changed OR there are other corresponding changes to the web application then you'll have to deploy the whole thing.
That said, I've seen shops that require a full recompile, deployment, and testing even if just one line of code inside a dependent assembly changed.
The full deployment part is pretty easy.
Right click on the web project and click Publish.
Publish either directly to the web server (I don't recommend this) or publish it to a local directory.
Make any config changes necessary for the production push.
If you publish to a local directory, copy the compiled files to your production server.
Some people say to delete the production files first, then copy. Others say copy to a new directory and repoint IIS to the new directory. You'll have to see what works for you.
Now, one thing web apps give you is config transformations. This means that you can let the compiler make config changes depending on the environment you are publishing to. I highly recommend you research and use these. It makes bad pushes much less likely.
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)
I have a C# console application written in Visual Studio 2008.
Usually I just build the application and then copy the files from the 'Release' folder but this time trying to do it 'properly' by publishing the application.
I went through the 'Publish Wizard' and end up with a 'Setup.exe' file in the specified folder. When running this setup file on another computer the install fails and indicates via a error message that:
Cannot download the application. The Application is missing required files...
When I select the 'details' button the error log shows that the program was trying to download files from the last version directory (ie 1_0_0_4).
What am I doing wrong? (aside from being tired...)
Show I de-activate the version auto-incrementing?
Unless you have a valid reason to do so, I would abandon the publishing and just go back to the XCopy installation. (And by Valid, I mean something other than someone told you that it's the "proper" way to do it.) I base this advice on the following arguments:
We used ClickOnce for all our WinForms apps for a while, but eventually it got to be more trouble than it was worth. For one thing, you need to deal with the security certificates. We had issues when we replaced a server with a new one with a different name, then we had issues when we replaced our development machines, etc.
You said this is a console application. ClickOnce publication seems to be overkill for a simple console application unless there are third party dependencies that you need to include in your install.
Don't get me wrong, I liked using ClickOnce for the ease of putting updates out there, and we use it still when it's the best option. However, in your situation, it looks to me like XCopy deployment should be sufficient for a simple console application.
Not knowing what you choose in the wizard, web or CD, the setup.exe file needs to be able to reference it's installation files. If using the CD method, you will notice in the output directory you revision directories, e.g. 1_0_0_4, where each revision of your app is kept. I agree with #David_Stratton, and unless you really need to use one-click publishing, don't. Just use xcopy (robocopy), zipfiles, etc. It will greatly reduce your stress levels down the road.
Everything David Stratton has stated is correct. ClickOnce is overkill for what you're trying to do, and publishing through Visual Studio has always given me headaches.
I might recommend taking a look at NSIS if you're looking for generating an installer for others. It's relatively simple to generate full installers that merely grab files from your /Release/ directory, with plenty of sample code for getting an installer working quickly. Once you have your working script, making your installers are as simple as a right-click and clicking compile.