Develop Reference

Why is my asp pages executing cached code

I've got an application I'm taking over with a very strange issue.
The background: 60+ identical IIS applications running on windows server 2012 that I rdp into.
Each application is identical except for some image files and the web.config files. (yeah, I know)
The applications are not compiled but just run as cs files. No proj files or sln files either.
There is one compiled app, which runs as a scheduled task, and uses some of the files in each of the application folders.
The code is C# and I'm editing it with notepad++.
The issue:
I've been trying to update some of the code in one of the test applications but my changes don't seem to be taking effect. (specifically update a log file and send emails). The current emails work but my new one does not appear, nor do my log files show up.
I tried to test it in another test application just to see if it failed there too, and found that that website came up with an error in some code on a specific line of a specific file.
Thing is, this line of code is not on the same line in the actual cs file.
I then added another line higher up to see if I could get a divide by zero error.
Same result. Same line of code failed with the same line number. No change at all.
Seems like my code is being cached and I can't refresh it.
I tried making sure it's not being cached by the only scheduled task and cycling IIS entirely (at the root).
Still happening.
I know for a fact that it's not a matter of an exe hiding somewhere as two weeks ago I made a change to the code and it worked. My change showed up. I also know for a fact that I am editing the correct file. I opened the folder using Explore in IIS.
There are no obj folders. There is a bin folder in each application folder but nothing in the bin folder except nuget package dlls.

Ok. So after I spent a week trying to set each app's web.config to use tempDirectory=a new temp directory based on the app name, I finally discovered that the previous coders had made two copies of the relevant file. Identical copies. One for use by a scheduled task and one for use by the website itself.
So all the time I was trying to detect changes in the result of my code, I was changing the one the scheduled task used.
Of course, in the several times I discussed the problem with the previous developer (who was still working with us), he never bothered suggesting the solution, although he's been working with this code for several yeas.
Updating the correct copy solved the problem. I've also discovered my head hair was shedding faster in the last few weeks than ever before.

Development on existing Umbraco-project

I have an existing Umbraco-project running on an IIS-server. When I started the project I basically installed Umbraco directly to the server and coded through the Admin-interface until the site was launched and went live.
Now, the customer wants some changes and it feels like I've painted myself into a corner here, since I obviously can't make changes in the code while the site is running. So, my question, which I hope this excellent community can help me out with:
How do I proceed when I get a copy of the project locally, to develop in Visual Studio and then publish it back to the live server? Should I create a GIT-repo, or is WebDeploy an option? Which workflow is the most convenient when developing and maintaining an Umbraco site?
I am also quite insecure about what configurations are needed on the IIS-server to support deployment from my local machine, so some input about that would be much appreciated!

Don't tell anyone, but for file updates only (like stylesheets or templates), I sometimes just FTP them up or publish to file system and copy/paste the files via RDP. If you make changes to document types etc., consider if you can't just test them locally and recreate the changes in the live environment afterwards.
Of course, this is only viable for small changes/solutions and one-man teams, but I feel that it's perfectly okay since the alternative(s) get very complex very quickly.
Edit: and also it requires you to keep your local copy pretty close to the live one, so you can be relatively sure stuff doesn't break when you "publish".

You'll have to get a copy of the files from the server, but also use a local copy of the database and update the connection string in web.config to point to that, otherwise any backoffice changes you make will be made on the live server.
If you are just making changes to views then some kind of publish from visual studio will probably work, but if you are making new document types, macros etc., this also involves data changes in the database which won't be published from visual studio at the same time.
There are various tools out there which cater for this situation of making development changes and moving them to live.
The obvious one is that you repeat all the changes you made in dev on the live server, although this can become tedious if there are lots of changes.
There are also things like Umbraco Courier and another one which I can't remember the name of for the life of me that copy all the relevant things from dev to live in one go.

Constantly get The local data store is currently in use by another operation when working on small projects

I use Visual Studio Team Services to store the source code of my projects as I work on them, I love the service, especially that it is free, but I have been running into the biggest pain lately.
Randomly when I go to save, modify, check in check out I get this error for every single file I am modifying. So if I am trying to save changes to 8 files I get this message 8 times and it takes 45 60 seconds of trying to check out for each file meaning to takes 6 - 8 minutes for the errors to stop (even if I hit cancel).
The local data store is currently in use by another operation
I looked it up online and found many people with the same issue but the response from MS has nothing to do with my situation.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
It basically says this can happen when you have to many files in your workspace or have several large solution open at once.
This does not apply to me as I usually only have on solution open at a time and my projects are very small (400 -500 files).

Ran into this issue as well on VS 2013 and TFS - every time I opened my team explorer it would take 10+ seconds to show all projects, then when I would expand the project in source control, another 10+ seconds would roll by.
Earlier today I began to experience the "local storage is being used" error when trying to save data in class files. I did some original research, and this following link saved the day for sure. Now TFS is blazing!
Local Data Store Solved
What you do is edit workspace (including all projects associated), and change the "Location" dropdown from "Local" to "Server". It took about 4-5 minutes for the changes to finish, but well worth it.
Hopefully this will help someone down the road.

Lately I started to get same error message and Visual Studio started to work very slow with TFS and nuget. I have tried repair and uninstall but not solve the problem. At the and it was so painfully slow that I cannot continue working. (Expanding one item on source control explorer takes 10 seconds)
Here is my story and how my problem be solved:
I was mapped tfs folders separately not to get whole TFS because there are lots of irrelevant documents. After trying lots of fix suggestion, I thought this might be the problem because I did this separate mapping first time while I have been using TFS. I generally map and get all items at once and never met this issue before.
I removed all mappings and it was like magic. Error is gone, slow TFS source control is gone and it is rocket fast now. Just to be in a safe side I also delete my workspaces and create a new one and get all TFS items at once.

I found the error would be triggered when I had more than once instance of VS 2012+ running utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows. I've not had this problem when running a single instance of VS 2012+ (on updates 2+) utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows in tandem.
I found this article and gave it's suggestion a shot: to prevent multiple threads from accessing the data store simultaneously.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
This proved to be a remedy for this issue.
I would add for other users with large file repositories, using source control and share this issue, it may be greatly beneficial to create multiple workspaces for each of your branches/repositories. I found that by doing this my queries to TFS sped up immensely and also helped with this error. I found this suggestion here: http://blogs.msdn.com/b/phkelley/archive/2013/05/30/using-multiple-workspaces-with-visual-studio.aspx. I share this as users mention TFS running slowly.

I also started getting the same error this week. Maybe there's something wrong with VS Update 3?
Simply could not work on any of the projects of the "broken" local workspace anymore.
VS would show all files as being checked out, but none were really.
Other local workspaces were working fine.
I tried removing a project from the workspace, but when trying to confirm it, I would receive the same TF400030 error again.
Suggestion
If nothing else works, you might want to try this: simply delete the whole workspace and create it again, this time separating projects into different workspaces. This worked for me.
You'll probably want to back up your files first.

I did as mentioned below and TFS started working fine
Close all the VS instances
Go to: C:\Users[UserName]\AppData\Local\Microsoft\VisualStudio\15.0_46af8b8e
Delete the privateregistry.bin file
Reopen the project solution
Above worked for me.

Had the same problem,can be fixed in 3 quick steps:
Remove current Workspace: Source Control Explorer->Work Space ListBox->workspaces... and remove the workspace.
- Make sure that all pending changes are checked in
Delete Workspace local folder.
- Its Better to delete the folder entirely.If eventually keeping some folders make sure to delete all $tf folders (hidden folders inside the workspace folder)
Remap the projects you need ( the less the better )
Hopes that helps.

In my case the cause was a compressed folder containing my local data store, shown in blue in Windows explorer. Removing the compression did the trick.

I ran into this error when renaming my workspace. After changing back to original everything worked fine again

Restarting the Visual studio resolved the issue for me.

Project looking in wrong directory for files(streams)

I've been building a game for the past couple of days. After i've reached certain milestones i'll C&P the project folder into my dropbox folder then create a new one in my visual studio folder.
I've run across a problem now however where when i'm trying to read from files the streamreader is trying to read from the previous folders directory.
SO for example in 'Project2' the reader is trying to read from a file in 'Project1'. How can I change this?

First, you're most likely specifying an absolute directory ( "C:\Blah\BlahBlahblah..." ) or you've set the Working Directory to the wrong place.
Use relative paths or always store your data in a fixed place (the convention these days is to store your data is APPDATA. Storing it in a place like Program Files is a HORRIBLE CONVENTION. Don't do it when you release your program for realsies). Having tagged this with XNA, your root directory should also be specified to a relative place ("Content", "Data", etc.) so that when the executable boots up, it'll look in where the executable is, + inside the folder "Content" or "Data". That will make using the Content Loader easier.
Now, a general recommendation. You should never have to create a new project entirely to do version control. You're literally doing the work of any good free Version Control System (or like this one). Version control will make this much less painful for you.
Finally, a last tip for SO: describing your problem is cool, but what's even better than all of that is combined is posting the code that throws an error. Doing this allows us to figure out what exactly what wrong, because the skilled professionals of SO (of which I am trying to become one) have dealt with and know how to handle many kinds of exceptions and compilation errors (that, or our Google-Fu is stronk).

Visual studio not updating project immediately

I have a very odd situation where by changes committed to the repository by my colleagues when updated to my local copy of the software, Visual studio doesn't recognise them immediately, and reload. the result (and this is very odd) is that most of the times, I will save my changes without the reloaded projects and will overwrite my colleagues changes. It is so embarrassing that sometimes I am asked why I had to change a piece of code and in reality I hadn't.
Another thing is, when I check in some VS project level changes like when someone added a new class, or form or anything and continue to work in Visual studio, it will take me at least 5 to 10 minutes before I get the warning that there was some changes and be asked to reload the project etc...
I think there should be a setting somewhere in visual studio to trigger an automatic reload, but can't find it.
This affect me and another person so far but mine is the strangest as it can take up to 30 minutes before a project start reload.
Any Ideas welcome
This is my settings

If you are working using Source Control, you will need to synchronise your local workspace with the server ("get" the latest code) before any changes by your colleagues will be copied to your PC.
If you don't "get" the latest code before you make changes then you may have to merge your changes with somebody else's, which can be a difficult, time consuming or even dangerous process - especially if you use the default Visual Studio automatic merge process, which usually does the wrong thing, resulting in essentially corrupt code (making it look like you deleted your colleague's works, just as you are describing, for example).
The best way to work with source control is the "little and often" approach:
Get the latest source code before you start any new work, so that your PC is as up to date as possible.
It's usually a good practice to "get" the latest code frequently (e.g. I do it first thing every morning) so that any merge conflicts are flagged up and dealt with as early as possible. The longer you wait before merging the worse the merge process tends to get. (Caveat: Check with your build system that the current version of the code on the server is working before you get it - you don't want to get broken code onto your PC as it may stop you being able to work at all).
Arrange your work as many small incremental steps that can be safely checked in as they are completed (rather than working for 3 months on hundreds of files and then dumping it on the system as one massive change )
When you are ready to check in, get the latest code, rebuild, and re-test your changes to be sure they still work when integrated with the latest program code. Only check in if everything works well.
Also be aware that when you try to edit a file, the source control provider may automatically "get" the latest version of that file for you (which could cause Visual Studio to tell you it has reloaded the file, and perhaps explain why you say it sometimes takes a while to "update", as it doesn't happen until you start editing a new file that has been changed recently by someone else). If this is the case, then the truth is that you have not "updated" the entire set of source code, only one file - in this case you really need to get all the latest changes to the source code (if you don't you may find it is uncompilable or (even worse), compiles but exhibits undefined behaviours due to only part of the code being up to date)
Lastly, a very good practice when checking in your code is to go through the list of files you are checking in and diff them one by one against the latest server code to see what you have changed. This may sound laborious but it confers several benefits:
It reminds you what you did, which can sometimes be helpful for filling in the check-in comment to clearly describe all your changes and make sure you don't miss an important note.
You will easily spot anything that has been screwed up in the merge process - there will be chunks of code that appear to be created or deleted that you know you didn't touch. So you'll be able to discover and fix these problems before you check in rather than annoying your colleagues by "deleting" their changes.
I find this very useful for finding temporary debugging code that I have forgotten to take out before I check in.
Sometimes you may even do a double-take on a bit of code you are about to check in and think "huh? why did I do that?". And then you might decide to re-examine and possibly even rewrite the code you thought was good to go.
Final Note: The options you show in your edit only relate to changes that are made to the files on your PC by another program on your PC. If another user makes a change and checks it in to source control, these options will have no effect. It is only when your Source Control system copies those changes to your PC's hard drive that you might see Visual Studio reacting to those changes (depending on how well your source control system is integrated with VS).

If you're sure the problem is Visual Studio (e.g. the file really has changed on the disk but you don't see it in Visual Studio)
Make sure that the Detect when file is changed option is checked.
Tools > Options > Environment > Documents > Detect when file is changed outside the environment

Since you are sometimes getting an alert to reload your project due to external changes means you already have the settings required to detect file changes in Visual Studio.
However, reloading of project/solution will only be triggered if the .csproj (or .vbproj) or .sln file was changed.
By the way, are you using some version control system? It seems that you are just sharing the solution and editing simultaneously.