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.
Related
I recompile my solution, and when it starts in debug mode I get this warnings around my breakpoint saying that it won't be hit.
There is a copy of the source code file that is different.
Why would there be multiple versions of my source code loaded when trying to debug?
I even do a clean compile and still get this error.
Visual Studio is usually pretty good at detecting when your source code doesn't match the code signature of your attached exe or dll process. So I suspect that it is one of two possible issues:
Your debug session's Platform/Configuration (e.g. Debug/x64) doesn't match the .exe or .dll compiled architecture. OR
What you think is a "clean compile" isn't really clean.
The only source code that Visual Studio knows about is the one in front of you. But when Visual Studio is debugging an .exe or .dll, it is attaching itself to the .exe or .dll process, using reflection, and analyzing the code of that .exe/.dll. It determined that your .exe/.dll doesn't match the Platform/Configuration you wish to debug, or its reflected source code doesn't match the written code that is in front of you in Visual Studio's IDE.
When you say that you do a clean compile, make sure that it is really really clean (don't rely on the Visual Studio "Clean" feature. It's not reliable in all cases. For example, if you have created Build Events that copy contents pre- or post-compile. Instead, delete your project's /bin and /obj folders, then recompile. That will ensure your binaries always match your latest code for debugging. Do this a few times, and see if you still get the issue.
I had same error in VS 2019 .I solved that way;
Tools->Options->Debbuging->General and "Require source files to exactly match the orginal version" deselect that option
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.
I've got licenses.licx file that is included to one of my projects properties. I am not sure how that is used by its dlls. Is it used by msbuild? Do you have any idea how it is used when the solution is building?
Since you indicate that StellarEleven's reply doesn't help, I guess you're looking for something even simpler. This is probably not 100% correct, but it is my understanding of how this works:
The licx file is simply a list of the "licensed" components used by your application.
Each line in the file is of the following format:
[Component Name], [Assembly Name]
For example one of my projects uses the licensed IP Works NetDial component so my .licx file contains the following line:
nsoftware.IPWorks.Netdial, nsoftware.IPWorks
In the context of the project (.csproj) file, the .licx file is referenced as an EmbeddedResource. During the build process, LC.exe verifies that the machine performing the build has the appropriate license(s) for the component in question, and generates a binary .licenses file which eventually gets embedded as a resource ([AssemblyName].exe.licenses) in the final executable.
Does this help?
Licenses.licx file woes
File this under ASP.NET, Department of WTF.
Frustration When you are developing a web application with our
controls, a mysterious file called licenses.licx appears. No, it's not
an order to use a weirdly-named lollipop, but is a transitional file
generated (and modified) by Visual Studio that participates in license
checking. In design mode, Visual Studio uses this file to make a note
of every licensed control you use in your design. When you then build
your application, Visual Studio read this licenses.licx file and for
every control mentioned there, will load the relevant assembly and run
the license code in that assembly to see if the assembly is properly
licensed (that is, that the product to which it belongs has been
properly installed on that machine). If everything checks out, Visual
Studio embeds the license key into the executable. If it doesn't,
you'll get weird error messages about the control not being licensed
(my favorite is "Could not transform licenses file 'licenses.licx'
into a binary resource." to which I usually invoke the colorful
language of my ancestors).
Licenses.licx is actually a file in your solution (if you cannot see
it there, click Show All Files). Visual Studio uses a program called
lc.exe to compile the licenses into embedded resources in your
application, and when things go wrong with the license compiling I've
seen error messages that reference this executable as well.
Here's an example of a line in a licenses.licx file.
DevExpress.XtraCharts.Web.WebChartControl,
DevExpress.XtraCharts.v8.2.Web, Version=8.2.4.0, Culture=neutral,
PublicKeyToken=9b171c9fd64da1d1
The first value in this comma delimited list is the class, the second
is the assembly where it's found, and the other values are the rest of
the assembly's strong name. I'm sure you can see problems already,
especially when you upgrade a solution to the latest versions of the
third-party controls you use. If you want, you can edit this file and
remove the strong name parts with no problem.
But that's not the biggest issue with licenses.licx. The thing is
Visual Studio has a propensity of touching this file if you open the
solution (that's "touching" as in changing the file date to the
current date/time). This plays havoc with licensing, especially if you
happen open the solution on a non-licensed machine and you are using
source control. Suddenly your build machine will throw off these
"cannot transform" messages and you're left wondering what went wrong.
Another prevalent issue is when you have a team of developers working
on a solution: they're all unconsciously "modifying" this file.
So, the answer seems to be not to put the licenses.licx file under
source control. (KB article)
But this solution to the problem throws another red flag: if one of
the developers in a team adds a new control that needs licensing to
the form, a line gets added to his local licenses.licx file and it may
not get reflected in source control. Bam, your build machine fails the
build and Joe, who added the control, has to buy doughnuts for the
team until someone else breaks the build.
I'm afraid I have no good solution to this latter issue, because
unfortunately the "not putting licenses.licx in source control" seems
to be the way everyone is solving the licensing problem. Another
solution is to delete the licenses.licx file altogether and then get
Visual Studio to regenerate it by opening the solution (although this
is a bit difficult on a build machine).
Anyway, hope that all helps in some way. And hitting your laptop with
a phone isn't really going to help.
We use a custom check-in policy (TFS) that explicitly nulls the contents of this while if present in the check-in list.
I have been making several improvements on code snippets that are typically built into VS2010. Is there any way to either "prefer" certain snippet directories over others, or to overwrite the defaults without manually removing the references from the Code Snippets window? I would like to keep the same shortcuts.
This is mostly nit-picking, since I could remove the .snippet files manually, or remove the folder references, but I'm wondering if there is an easier way, incase I end up replacing a large amount of the default snippets yet still want to keep others.
There are two issues that come up when having similar shortcuts on code snippets.
For some snippets, such as propdp, you will be prompted that there are multiple snippets, and be asked to choose which one is appropriate.
For other snippets, such as ctor, it just uses the default snippet and pretends my own doesn't exist. Browsing the snippets using Ctrl+K,Ctrl+X clearly shows the snippet works, and the shortcut is correct.
The second issue here is a larger concern than the first.
Edit: Further experimentation shows that ctor in particular uses the default snippet no matter what. I haven't tried overwriting the code in the original snippet file, but removing the reference to Visual C# snippets folder still uses the default and ignores my replacement.
Edit 2: Even replacing the original snippet, ctor uses the default and ignores the .snippet file. This is after restarting Visual Studio as well. Now I have no idea where it's even retrieving this code snippet from. As a test, you can rename the snippet ctors and it will display properly. ctor is no longer a suggestion at this point. If you rename it back to ctor, it will once again display the default snippet. Either this snippet is cached somewhere, or it's built in to VS2010.
Have you tried simply overwriting the original files, replacing the snippet with your own?
They're located here: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC#\Snippets\1033\Visual C#
On my system, the C# snippets are stored in two places at least:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC#\Snippets\1033\Visual C#
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC#\Snippets\1033\Visual C#
I think you're right that Microsoft's snippets always "win" when you have snippets in other directories, so to use customized snippets, you end up having to overwrite the originals. But every couple of weeks when an update to Visual Studio is released, the update will obliterate your versions in favor of MS's. (Why did they bother to expose this functionality if they're going to disrespectfully ignore or obliterate your customizations?)
I ended up just writing a program that starts running at login time to watch these two directories. When something changes in one of them, it compares the snippets there to ones I have stored in a "snippet override" directory, and if they aren't the same, it restores my versions of the snippets.
Have you looked at the plug-in for Code Barrel? It has revision support, tagging, etc... Looks like that may be what you need. ~shrug~ it is free, so is the plugin, go to codebarrel.com to get it.
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.