I'm making a small package in SSIS (Integration Services), and in my control flow I have a couple of script tasks and some data flows reading data from XML files into the database.
I made some edits to the C# code in a script task in the built-in Visual Studio editor, and hit save. The star by the file name disappeared, indicating the file was saved. I closed the Visual Studio editor, saved the package, right-clicked the script task and chose "Execute task". It ran without errors, but the XML files it was supposed to create never appeared, so I opened the script in the Visual Studio editor again, and to my horror only the default script was there (e.g. only the main method and it only contained the Dts.TaskResult = (int)ScriptResults.Success; statement)!
I have been unable to find the code I had in that script task, and when I open the .dtsx file in a text editor my code is gone! The code in the other script task is there though.
I was paying careful attention, so there's no way I mistakenly deleted everything before closing the editor and saving the package.
So my question is: Has anyone else encountered this totally insane bug, and is there a way to recover the code; or do I just have to bite the bullet and recreate it from memory?
We rarely use any significant amount of C# code in these SSIS jobs, so we don't have any integrated VCS. I have been copying the code to a new file and manually adding it to my own Git repo, just to be safe, but I hadn't done that yet with this particular code.
And I just have to restate my frustration with such an amazingly bad bug in Visual Studio...
I am having a similar issue. It is reproducible. The code exists in a script task inside a foreach container. You can go in and view the code to confirm it exists as well as the variables set for read and readwrite. Next go to the foreach (parent container) and change a variable mapping. Go back to the script task and the code is gone. I have even made it as simple as no variables being used inside the script task and only putting in some comments. And it still happens and reverts back to the default code.
Related
I am not new to coding and I know I have never had this issue.
In Visual Studio if I just create a .cs file and check it's intellisense nothing works. auto complete for using. does not work, nor does simple syntax checking work (see image)
Am I crazy? Can someone else try this out, what am I missing?
NOTE this only happens when I just have a .cs file for an external script. I just need simple auto complete and syntax checking to work
A C# file is somewhat meaningless without a project file. Versions, references, etc… all depend upon having a build system. This is a somewhat pedantic truth, but it is how VS works. Pathologically, I could have a CS file Console.WriteLine(“Hello world!”); which in one project results in hello world, and in another results in the program formatting a disk.
Add the CS file to a project, or create one. If you frequently come across this issue in some unique use case, visual studio may not be the best editor for the job. VS Code or another more lightweight tool may be better suited.
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.
I am working on an Asp.net web application. Since yesterday I am unable to check in my code. But I am able to get latest code, compare files , View history and create work items.
While check in- Neither the error message is displayed nor The file that needs to be checked in is locked.
Suspect:-
The application is written for VS 2010. But,Once I opened it on vs 2012. Later I made necessary changes to the solution file so that It re-opens on VS 2010 again. Can this be the reason why check in is not working? Please let me now if you have any suggestions. Thanks.
"Lock "Check-in". This is also known as the "antisocial":-). A check-in lock prevents anyone else from committing their changes to that file until you have released the lock. This means that they will be responsible for performing any conflict resolution activities that result. You can place a check-in lock on a file even if somebody has a file checked out with a lock type of "none" i.e. I know you are working on this file but you are not allowed to check in your changes until I have made this important quick fix."
Probably this is the case, someone check out the file after your check out. Check who check out the file and contact with him, this is the best advice which I can give you.
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.
Trying to debug a controllers action method, and when I attach to process the debug icon goes hollow and says the 'current breakpoint will not be hit'
But I am doing a response.write at that point and when the page renders it does output the test text.
So that section is indeed being executed, why does debug mode not work?
Your source code may be different than the version of the corresponding process that you are attaching to. Your other process may also be built in release mode, i.e., there is no debug info.
There are a few reasons why you may see this message:
You are attached to the wrong process
You are attached to the right process but the AppDomain hasn't loaded the assembly yet
You are attached to the right process but you have forgotten to build so the source code and the PDB file are out of sync
I've noticed this happen when using reflection and dynamically loading .dll projects. If the code isn't specifically reference (i.e. you are using interface animal but dynamically loading implementations of animal such as cat/dog) it will say it won't hit the breakpoint, but actually does.
I do not like to play with knives but the only thing that worked for me involves editing the .csproj file itself. So, unload the project file, edit it by cutting and pasting the three asp.net files so that they are together in the ItemGroup. However, sometimes it is necessary to go further as explained here: http://carnotaurus.tumblr.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same - Also, I give a list of other proposed solutions that did not work for me. I hope it helps.
Another reason is when you attach to the process to quickly.
For example, when I attach to Excel to debug a VSTO add-in (I am using Add-In Express), if I Build, then Start > Run > Excel, then quickly press Ctrl+Alt+P to attach to process, then press E to highlight Excel and press Enter I see this, before Excel has loaded:
The result is no Breakpoints will be hit.
However, if I give Excel a couple of seconds to load and then press Ctrl+Alt+P, notice the Title is showing:
The result is Breakpoints will be hit.
It also tells me your source code is different from the version but it is not true. I build the whole solution, then attach to process, but still it says the breakpoints won't be hit because the source code is different. Maybe it is a bug?