Ok, I know this is a very old product so I'm hoping there are still a few of us old timers still out there who can help me.
Internally we have several old systems which are in the process of being migrated to c# however routine work is still required within them.
We have had a problem for quite some time and it appears to be getting worse, in fact it was mostly noticed since upgrading to Windows 10.
To give an example one project consists of the main application and 19 dll's all grouped within the project. Any part of the project can be compiled and works fine, but other times I can compile a dll and the dll vbp file gets corrupted.
Corruption could be...
Duplication
Reference=*\G{72F49028-2BDA-4107-9870-FA71E3F7DFA9}#3.3#0#..\..\..\..\..\DLLStore\VB6\Search.dll#
Reference=*\G{72F49028-2BDA-4107-9870-FA71E3F7DFA9}#3.3#0#..\..\..\..\..\DLLStore\VB6\Search.dll#
Or incorrect reference guid
Reference=*\G{72F6675-2BDA-4133-9778-FA71E3F7DE3}#1.2#0#..\windows\---\COMDLG32.OCX (I've forgotten the exact text)
Object={F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0; COMDLG32.OCX
Removing the reference line fixes this.
I know I could mark the vbp to be read only and then keep changing it as required but I need to get to the bottom of what is causing it in the first place.
Any pointers are greatly received :-)
Related
Yes, I've seen this previous question here and none of the solutions have worked.
On Visual Studio Community 2019 I was debugging a project that I've been working on for years. I have a common library project, that I've built, that I use on multiple solutions - one web, one exe.
In working on the EXE solution, which is one windows app project + about half a dozen other custom libraries, I was debugging along without issue. Changed a bit of code and then started another debugging cycle and suddenly symbols couldn't be loaded for one of the libraries.
If I look in the output folder, the PDB file for the library IS there. If I look in the Debugging Windows... Modules, the library does NOT show up.
If I load up the web project which also uses this library, it debugs fine and the module shows up in the modules window.
I've tried everything in the thread I've referenced above. I've also tried:
Build, Clean, rebuild, in all sorts of different orders - the PDB is ALWAYS there.
Removing and readding references to the project from the EXE
Creating a whole new solution
Going to a different PC entirely - one that I knew was working yesterday - grabbing my latest code, and still the same problem.
Reverting back to several different old branches of code, on BOTH the new machine and the old machine, same issue.
Installing VS updates
Repairing VS
Checking my GAC to make sure there was nothing for these libraries in there
Played with every project setting I could find
Cursing and praying to the programming Gods
I have no clue what to do next. Obviously this one specific project is not loading the DLL, but I can't figure out any possible reason why. The only thing that changed between a successful debug and the missing symbols error was me changing a few lines of code and clicking Run again. (And I even removed the code changes and it still failed.)
I just don't understand what could have caused this, for this singular library, on this single solution.
To anyone who finds this later, I've solved the problem and my code is debugging fine again.
And I have zero clue about what changed, why it started working, or if I even did anything at all. I came back to it the next day, systematically started working through various tests, and suddenly everything was fine - though I didn't do anything differently than the day before.
These are the times that try men's souls.
I'm very new to Visual Studio and Universal Windows Apps Development. As a part of the course, I have this codeSHOW project provided.
I've cloned it successfully in VS 2015, but I can't run the project using the .sln file. Error:
Here's the error log: http://pastebin.com/c012Bba4
I have no clue how to fix it, and the issues on github go unanswered so I can't expect much from there.
This is an known issue in Visual Studio 2015.
The problem is with files with the exact same name under different folders in a Shared project, which in your case is "resources.resjson".
The only workarounds are either to make the file names unique and if that is not an option, to duplicate the files in the projects instead of sharing them out of the Shared project.
This is a VS2015 specific bug, the solution loads just fine on VS2013. You can get some insight into what is going wrong. First note that your got two message boxes that announced this error. Barely visible in your screenshot.
The failure.txt file gives more hints, you can see the stack traces of the two AggregateException that are raised when the solution is loaded. You'll see that two tasks are trying to load the same resources.resjon project item. Not correct of course, quacks like a standard concurrency bug.
Nothing actually goes wrong, Visual Studio can handle the exception and declares it "Recoverable", the projects are still loaded correctly. And compile just fine. Only other thing you need is the Bing Maps SDK, you can download the correct version here.
If you have VS2013 then prefer that version, it doesn't have this bug and loads the solution without any complaint. And minimizes the odds that you'll run into other quirky problems. Given the current stability of VS2015, not great, it is the best way to avoid losing time. Otherwise just ignore the mishap and close the message boxes, some future Update will no doubt fix the bug. You can report it at connect.microsoft.com if you wish. Not actually necessary I think, it looks like VS is phoning home.
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
I am using Visual Studio and a solution with 10 or so projects in (mostly VB, some C#) which have various dependencies set up. Usually when I compile the solution it works fine. Occasionally when I do it I get a build error saying that one of the projects referenced is the wrong version (I think always the same one, possibly may be two that can cause problems). In this case going to the solution explorer and right clicking on the mentioned project and saying "rebuild" followed by another full build makes it work fine.
I assume there is something set up wrong somewhere but I didn't set up the solution myself initially and a quick look through doesn't show anything immediately wrong.
It feels like there is some kind of race condition, that VS is internally setting the version number of the project it needs before that project has been rebuilt and thus gets it wrong or something like that but I'm sure VS should handle all this sort of thing properly.
Can anybody please suggest places that I could check for whether this has been correctly set up...
And I should finally note that since I don't have reliable repro of this I may not be able to respond to questions too quickly. For example the obvious one of "Could you give the exact error message" will have to wait since I didn't think to copy it this morning, it was only after I cleared it up with the above steps that I thought to post here. Similarly any solutions may take a while to confirm.
Edit to add error message:
Indirect reference is being made to assembly ODP version 1.0.3792.16586, which contains '{{CLASSNAME}}'. This Project references a prior version of ODP version 1.0.3791.18659. To use '{{CLASSNAME}}', you must replace the reference to ODP with version 1.0.3792.16586 or higher.
Edit for more apparently relevant details
Since it has been bought up I will clarify that one of the projects is a web project and that it is this one which is generating the above error message.
Further edit
Having looked further there is a copy of ODP.dll in the bin diretory of my web project. Using windows explorer and right clicking, asking for properties and looking at the version it is version 1.0.3791.18659. Having deleted this (actually moved it elsewhere) when doing a build it recreated this file still with that same version number (ie an old version number).
ODP claims to be a project reference too which still makes me think it should just work... :(
Further Further edit
I think now that the problem is that if the ODP project changes then it gets rebuilt but it doesn't necessary cause all the projets that are dependant on it to be rebuilt. So one project might still be built against the old version and one against the new version. If they are then trying to talk between each otehr with objects from ODP then it goes wrong... I need to confirm this but I'm not sure what would need to be done to fix it at the moment. :)
Is the build order correct? I can imagine if you build one project which references the other one, and that one isn't built yet you can have this kind of problem.
Link: http://msdn.microsoft.com/en-us/library/5tdasz7h%28v=VS.80%29.aspx
If you have a website project, are you sure you have set these to be 'project' references rather than 'bin' references - you could be getting some issues this way.
This is driving me crazy and has resulted in lost work (not much, at least).
Normally, when I edit a file in Visual Studio, it's supposed to automatically check that file out in source safe. On multi-project solutions (e.g., web app with class libraries), sometimes none of the files in one project would automatically get checked out, though exiting & reloading visual studio may fix that problem temporarily. Furthermore, project files are never automatically checked out. Whenever I add/remove code files, I have to remember to explicitly check out the project file as well (otherwise we'll have issues with code files not showing up in the solution explorer, or trying to load non-existing files).
We're using VS-2008 and VSS 2005. Do you have any idea how I might fix this? There are no more visual-studio updates/fixes on Microsoft Update.
You need to ensure the files are read-only, or VS won't be able to tell that they are version controlled (or, at least that's what it uses to determine it). You can tell VSS to set itself up so getting the latest version places the files RW on disk.
There may be other problems here, but that's what comes to mind first. My advice (that I took myself) is to migrate to SVN or an alternative. Losing work is unacceptable.