C# visual studio project: Properties.Settings.Default.SomeValueOrAnother has me baffled.
I have a relatively simple project. It saves a bunch of last-entered values between sessions, and restores them on next invocation. Was working fine. I changed a control so that the minimum allowed value was no longer 1, but was now 100. Last used value had been 3. On startup, it now complains that 3 is not a valid value.
Well, duh, of course – but hear the rest.
I have edited Settings in VS to default to 500. I have edited the exename.config file to contain 500 instead of 3. I have examined every possible config file (vshost.exe.config, the files in bin/debug, bin/release, obj/debug, obj/release. They all contain value=500. I have re-built repeatedly. I have copied just the exe and the config file to a separate PC, so that the development environment was not a factor. I still get this error message.
To further confuse me, on the dev PC, if I run (directly, not in the debugger) the exe in /obj/debug or /obj/release I do NOT get the error. If I run the ones under /bin I DO get the error. The config files have identical contents. If I copy the exe & config from /obj (the one that does not give an error on the dev PC) to another PC, I DO get the error.
I thought exename.config was all I had to deal with, but it looks like VS is doing something behind my back – at least something that I cannot find in the documentation. I imagine this is something trivial. If anyone can explain what I've missed I'd sure appreciate it. All I really want to do is reliably save some user settings from one run of the program to the next. And get this app to 'forget' that obsolete value.
TIA
Mickey
Look for *.settings files in your solution. That's where the value that's used when you build your project will be stored .
This was not the entire answer, but it did explain where the mystery values were being stored:
"This might help to some people dealing with Settings.settings and App.config: Watch out for GenerateDefaultValueInCode attribute in the Properties pane while editing any of the values in the Settings.settings grid in Visual Studio (VS2008 in my case). If you set GenerateDefaultValueInCode to True (True is the default here!), the default value is compiled into the exe (or dll), you can find it embeded in the file when you open it in a plain text editor. I was working on a console application and if I had defaults in the exe, the application always ignored the config file place in the same directory! Quite a nightmare and no information about this on the whole internet."
...in another post here. I am now individually testing values read from settings, rather than trusting it, and forcing them into valid range if required.
Truly an ugly, and well hidden, default. I haven't embedded data values in my executables since the days of CPM. Jeesh.
Thanks again, Microsoft.
Related
I'm working on a windows service and using SlowCheetah to manage the transforms. I added some settings and therefore updated the app.config file for the first time in months, and for some reason when I build the Debug configuration it generates an old version of app.config with a modify date from six weeks ago (Jan 3rd.)
To make matters worse, looking through the source control history it doesn't look like the file was ever checked in with the changes that are showing up when I build. That is, one setting is set to a different url for me to test something... but that was never checked in.
If I build in Release or Test configurations it works perfectly.
I've tried:
cleaning/rebuilding the solution
Deleting/recreating the the app.config file (It generated the 1/3 version even - when I build with file deleted!)
Restarting Visual Studio
Rebooting my computer
Nothing works and none of the changes I make in the config file are reflected when I build Debug.
Any ideas why or how to fix it?
Did you try looking at the post build section? Sounds like something there is overriding the built version with a previous one.
I am working on a project and while compiling, my laptop handed up and I have to turn it off manually.
After the restart I found that my code is not showing up. There is no line of code in program.cs file.
I am working on that code since a month. And all of it vanished.
Need help. I have the executable file working properly. But i need the code. Is there any way to find that code ?
Use ILSpy to decompile your executable. You will get the source code back, minus the comments. This is possible because assemblies (like your exe) actually contain "Intermediate Language" (IL), and not native machine code/assembler. From the IL it is possible to get a reasonable representation of the original source code. You may need to recreate the csproj file manually, if you do not have it.
If you have the .exe you must have compiled it, if you compiled it you must have saved it.
Where it is depends on where you saved it. Easiest thing would be to use the search function in Windows – search for whatever you called your program, or failing that, *.csproj. Then you can open the csproj file with Visual Studio and you should get most of it back.
I'll give you 2 versions of my problem to describe it, first the short version.
When I try to build my application it does that perfectly and my app works but when I try to rebuild it, that fails and gives an error message saying that 2 files are missing (bin/debug/MusicPlayer.exe and bin/debug/MusicPlayer.pdb). When I then try to build normally, it fails to with the same error.
Now the longer version:
The way this happened was quite out of nowhere, I program on 2 different locations (both in Visual Studio 2010 sp1) but to always have the recent version in the right place I copy the entire solution folder to a usb stick, this folder I copy over again on the other PC and use it to continue were I left off, I've done this many times without problem. Yesterday however, I got an exception while testing the app. But instead of showing this in my code, it was complaining that it could not find the program.cs file (it was there, but apparently it had a different checksum (md5) and it asked me to use this one. After a while I found what part of my code caused the exception and fixed it. Since then I haven't got that error anymore. But when I later tried to rebuild instead of build, it gave me the error described in the short version. I have tried to fix it, but apparently I was not very successful.
Basically, what I think it does is delete the files in the debug folder that need rebuilding and then gives me the error of missing files (the files that it deleted) and thus failing to rebuild succesfully because these deleted files the normal build option won't work to.
(What I then do is re-copy them from my usb to make the normal build work).
Don't know if it's important, but I program in C# and I'm still learning.
Also when I copied it to my usb I believe I had no errors and the app was working fine (except the part I fixed later, which I could not test at that location). And when I build the entire solution it gives some warning ==> "Assembly 'bun/debug/MusicPlayer.exe' is incorrectly specified as file" and this for 5 files.
Does anyone know how to fix this rebuild problem and if necessary the warnings?
Thanks in advance
(and sorry for my bad English)
OK it seems like you might be confusing yourself with your directory structure here. If you want to add Content or Resources (Images, Text Files, etc.) you should place them in a folder within your project (not called bin or obj). All your build files will go here. Instead place the Content in another folder and Right Click -> Properties and Set the build action to "Content" or "Resource" and set the Copy to Output Directory (bin folder) to "Do not Copy" or "Copy if newer."
The project is failing because you have the built executable "MusicPlayer.exe" in your project. So Visual Studio is trying to build an executable file in adding to the project. Restructure your directories or remove "MusicPlayer.exe" ever time your build your project.
Do you have any anti-virus software running? They can go way too aggressive on removable drives. You are actually continuously deleting and creating a runnable program on usb stick by recompiling.
Just a guess tho...
Sounds to me like you have a pre- or post-build event with a hardcoded path in it. Fix that using variables and it should be ok.
What to do now, this time??
I hate VS and this symbolic gibberish that never seem to have same solution (if it once was logic) twice. The screendump below says what it says.
As soon as I F5/Start the web project, the breakpoint going yellow. This ONLY affect the aspx.cs file that being changed. The other aspx.cs files can have breakpoints.
When I do rebuild/build all DLL and PDB files are created just fine. They have same compile time and are in same directory. Module-Windows i VS says the symbols are loaded perfectly. Well, yeah, try bite me!
I can tell, all symbolic is working just fine, until I was about doing changes inside those aspx.cs files (which was some time ago since last time). If I reset back the file, the breakpoint are working. If I try to make changes in another file, the problem appears there.
It simply appears like that the symbolic file generator don't understand changes maded in aspx.cs files..
Have you got compilation debug="true" set in web.config?
http://msdn.microsoft.com/en-us/library/e8z01xdh(VS.80).aspx
This sometimes happens if you have changed the starting url in the Web -> Start Action -> Start URL to a different location. It could also be something in the Web -> Servers pane where something is set other as expected.
Also make sure the website in IIS (if you have configured IIS) is located to the right directory (where your project builds the output), otherwise it can't start debugging either.
I've found a good hint (see my comment higher in this thread).
The WEBAPP have, as seen above, an _dll path.
This _dll path are there because this project has dll files shared with other projects. This means save space and don't have copies of same files for several projects.
Though,
This raise problems beause the webapp still are output/copy files to it's own sub bin/ directory. And even worse, not ALL needed dlls, which make error when the running web project (due to missing xxWeb.dll, which copies to _dll bin).
Accepting the fact to use standard bin/ fixed the problem this time. Why? The answer on that will not be in this thread, sorry. Someone with an idea would course make a comment here. In general, this isn't a drawback because the webb project binaries should be at the end of reference tree..
Open Visual Studio Command Prompt
and Run devenv /resetsettings
I'm working in VS 2008 and have three projects in one solution. I'm debugging by attaching to a .net process invoked by a third party app (SalesLogix, a CRM app).
Once it has attached to the process and I attempt to set a breakpoint in one of the projects, it doesn't set a breakpoint in that file. It actually switches the current tab to another file in another project and sets a breakpoint in that document. If the file isn't open, it even goes so far as to open it for me. I can't explain this. I've got no clue. Anyone seen such odd behavior? I wouldn't believe it if I wasn't seeing it myself.
A little more info: if I set a breakpoint before attaching, it shows the "red dot" and says no symbols loaded...no problem...I expect that. When I attach and invoke my .net code from SalesLogix and switch back to VS, my breakpoint is completely gone (not even a warning that the source doesn't match the debug file). When I attempt to manually load the debug file, then I get a message that the symbol file does not match the module. The .pdb and the .dll are timestamped the same, so I'm stumped.
Anyone have any ideas?
Thx,
Jeff
I saw this functionality in older versions of VS.Net (2003 I think). It may still exist in current versions, but I haven't encountered it. Seems that files with the same name, even in different directories confuse VS.Net, and it ends up setting a break point in a file with the same name. May only happen if the classes in the file both have the same name also. So much for namespaces I guess.
You also may want to check your build configuration to make sure that all the projects are in fact building in debug mode. I know I've been caught a couple times when the configuration got changed somehow for the solution, and some projects weren't compiling in debug mode.
Kibbee, you were right! It was two files with the same name in different folders. I was setting the breakpoint in the correct file on line 58 - it was putting the breakpoint on the other file at line 58. I was finally able to set a breakpoint by using the "Debug-->New Breakpoint-->Break at Function Name" menu option and entering my function name. It stopped exactly like it should have then.
I agree - so much for namespaces, right? Damn thing cost me a couple of hours. Oh, well...at least it's solved and I know why.
Thx for the answer and thx to Matt for his reply, too!