On the compile tab of the project properties:
If you look at the configuration dropdown it typically shows debug/release/active/all.
I attempted to add another option at one point in the build->configuration manager window, but decided that I didn't want to keep it. I removed it there, but it keeps showing up in the dropdown on the properties, as well as generates a folder by that name.
Does anyone know how to remove this? I can't find any "delete" or otherwise options.
You likely just removed it at one level. Check the configuration manager on your Solution, and then on each of the projects within the Solution, and make sure it's removed from each.
(By going to the drop down, clicking , then remove just as you did before)
Related
I have a sliverlight web application in VS2010. I have several projects in the solution,
one of them I use as a library of dialog boxes and other screens used in the other projects.
I edited one such dialog box, a child window, and added an extra row to the layout grid and
a combobox to the row. I rebuilt the soluition and my change appears in one sub-project but
not in another.
For the purpose of discussion here are the module names:
Manage - uses the child window 'add' in SilverlightClassLibrary2
Policy - uses the child window 'add' in SilverlightClassLibrary2
SilverlightClassLibrary2 - contains the child window 'add'
Note that this has been working for years until now.
My first indication of a problem was I could not hit a break point in Manage, it would
say no symbols loaded. I checked the references to SilverlightClassLibrary2 and they point
to the correct dll in the debug folder. A full recompile changes the date-time stamp of
the SilverlightClassLibrary2.dll everywhere. I deleted all dll's manually and re-compiled
and still manage has the old version of 'add' and policy has the new changes.
I'm at a loss as to where manage is getting an old copy of SilverlightClassLibrary2.dll
It is obviously looking somewhere else, this would also explain why the symbols are not
being loaded. It's not looking in the release folder, even so I re-compiled in release mode
to make sure it too had the changes. I deleted and re-added the reference (a project reference) to the SilverlightclassLibrary2.dll, still the same problem.
So where can I look to figure out what is going on with this?
SOLVED:
ahhhhhhh...it was chrome's browser cache that was giving me the old code.
As for the breakpoint issue, solved by using IE8 (i'm on xp) instead of chrome.
ahhhhhh...it was chrome's browser cache. I cleared it and now I see my changes.
Still can't hit the break point in chrome (no symbols loaded for some modules) even after clearing chrome's cache, but the breakpoints do work in IE8.
There was a suggestion to look at debug -> windows -> modules and locate the errant module and manually load symbols - but the module I want is not listed even though I navigate my app to the page in question. I use a line like this:
dim cw as new SilverlightClassLibrary2.Add
to create the child window, so perhaps this does not show up in the module list when using chrome? In IE8 the SilverlightClassLibrary2 module does show up in the list. strange.
This may be a simple question, but I'm not even sure of the search terms to find the answer.
I have two winforms applications which have been derived from the same code. One supersedes the other, but occasionally we have to us the older VB app for legacy information.
The problem is, if one app is already open, when the icon of the other app is clicked, nothing happens. The currently open app's window becomes selected like it has just been opened. Nothing else.
What I would like to happen is that both apps can open at the same time. They reference different DB's so there's not clash there.
I thought it might be something to do with the name spaces, so I changed those, but to no avail.
Any thoughts, I'm sure its a simple answer.
Mark
Look at Project Settings (Double Click on "My Project" in the Project Explorer).
In the Application-Tab you'll find the setting "Create Single Instance Application"
(I'm translating from German Version, may be slighlty different).
Better Alternative:
Basicly it is useful to keep this setting as it is and go for the alternative:
In that same spot, you find a button "Assembly Information". Click on that and change the first number of the "Assembly Version". Now the older and newer versions are two different programs for Windows and will run parallel.
Go to, 'project properties', Tab 'Application', section 'Windows application framework properties'. There is a checkbox called 'Make single instance application'. Maybe that's on...
I had the same problem with two applications. They had different assembly versions and I wanted to avoid unchecking "Make single instance application", so I kept looking until I found that they had the same GUID. Just changed one of them and problem solved. You can change the GUID in the Assembly Information dialog. Hope it helps.
I'm sure there is a simple option for this but I have as yet been unable to find it. Every time I close and reopen Aptana Studio 3 it collapses all the folders in the project explorer and I have to reopen them all, is there a way to get it to leave them open and save the project explorer's state when I close the program?
Thanks.
I cannot find any way to keep the state of the Project Explorer. However, using the App Explorer, the state of your open folder will be preserved. You can also try the "Navigator" which looks just like the Project Explorer, but appears to keep state. I will add the proviso to that: It kept state when I restarted aptana, but it also developed a GUI glitch where it appears to be scrolled to the right so I only see the right half of all of my file names and I cannot fix it, so this may not be a good option if you get the same glitch.
There is also a method which does not do quite what you ask, but may be a good fix for you anyway. If you click "Link with Editor" picture (two yellow arrows) in the Project Editor, it will automatically expand your project hierarchy to match whichever open file you have active. Since your files stay open when you close Aptana, this would keep the Project Explorer expanded to whatever you are looking at even on restart. See this question
You can also set up working sets for various parts of your code that are buried in the hierarchy and use the Project Explorer to show those working sets instead of you projects. This does not save state, but it does give you easy access to common parts of your code that may be deeply buried.
Hope one of these helps you.
I have an Xcode 4 objective-C project which contains about 150 .m and .h files in it.
The code underlying the project does not always correspond in underlying disk structure to the folders shown in the Xcode project. I get that part.
What I don't get is why Xcode won't tell me anything about why I can create new project groups and move items to them, with no problems, but certain existing project folders will cause the project to become broken, and the code will no longer build once I move certain .m files or .h files into a different group. When its broken it just shows the file in red. This is frustrating and confusing.
In the screenshot below, the left side of image before shows state before, when all is good, right side shows red (missing) file after moving into a group. Given that groups don't represent a folder on disk, I would not expect moving from one group to another to break things. Sometimes it does, and sometimes it does not. This particular XCode issue upsets me a lot.
In the good old days of Friendly Mac User-Interfaces, you could hit ⌘+I and get some information about the properties of objects, or right click and get to the properties of something via its context menu. Groups (folder icons) in XCode projects have no properties item in their context (right click menu) and yet these groups all clearly NOT all alike. What's up with these identical looking groups?
Secondly, how does a person learn how to reorganize both the on-disk-folder-organization and the visual group organization, in a way that does not leave you bloodied and beaten? (XCode 4 is the most difficult IDE version I have ever used, for this, I'm sure I've missed some important documentation on dealing with folders and files and so on.)
Update: The File Inspector (Identity Inspector in Utilities menu) is the key to this mystery, but exactly how a new user is to discover this (other than by painful experience) is still unknown to me. I also don't really understand what all this is about, with various choices available in the Path drop-down, and the blank or non blank value that has no description or help, just a cryptic icon and either a name of some real on-disk-folder or else a gray text field saying None:
This sort of thing doesn't just happen out of the blue. In this case, what has happened is that a user has opened an .xcodeproj and is unaware of the difference between the various relative or absolute Path options that a Group can be a part of. A Group in XCode is always shown with exactly the same manilla color folder-icon inside your XCode project, no matter what modes or properties it has defined inside of it.
By default the simplest case is that you create a new folder Group object in XCode and it's purely a cosmetic organizational tool that has no disk location information stored in it.
This is not the ONLY thing that these groups do, and not the only "mode" that these groups can be used in. These groups can also be used to point at some folder and say "things that are in this virtual folder are really somewhere else, either underneath this project's main folder in a subdirectory, or even up somewhere else on your hard-drive, either stored in relative path, or absolute path format". When used like this, these things remind me of a Windows "Shortcut" object on the desktop, or a Mac "Alias" object in the finder.
Dragging a file from one group to another does not move it to a different folder on the disk. It simply moves a reference to a file with a certain name, to another group, which might mean that after you drag a file, you haven't really moved it, or copied, or relocated it in any way, you've just moved an alias from a place where it could resolve properly to a real file, to a place where it can't. Thus XCode helpfully turns it red for you, without any helpful error message about what happened.
How do you fix it? In this case, go to the Identity inspector pane in the Utilities menu, and either decide to clear out the bogus value in the place where I have shown in the picture in the original question where I had "Classes". Clearing out a value that is invalid is not exactly easy to do because XCode requires that you basically find the root folder of your project and select that, and that will 'clear" the relative or absolute path property on your folder-group.
Alternatively, you can leave the folder alone, and just don't drag files from group A to group B without first checking what relative or absolute path they reference.
What still seems horrible to me is that XCode tutorials tell you to "use XCode to manage your project's contents, don't just drag files around in the finder inside an XCode project directory", and that's good advice, but it leads me to assume that XCode provides full and intuitive physical (and virtual) group-folder organization tools. It does not. As an example, imagine you inherit a project that has .m and .h files scattered through four physical folders underneath the main XCode project folder and you want to move those files around. You have to do a combination of tricky things inside XCode, and either in Terminal or in the Finder, in order to reorganize your folder. With the complications involved in moving items around in your version control tool of choice added upon the top of that, and XCode's very limited support for only Git and Subversion, you have a really tricky mess.
My question is on how custom controls should be updated.
I downloaded this owner drawn custom control, which I built, then copied the DLL to the Debug folder of the project and loaded it into the toolbox from there.
I decided to use this button on another project. I was mildly surprised to see the control was still in the toolbox but it seemed to work just fine. I decided to change this custom button's behavior. The button in the toolbox referenced the old version number. So I deleted it and loaded the newly rebuilt DLL.
Now come the problems. The first application--the one where the DLL was added to the toolbox from--still runs okay, but the second application is throwing errors, saying, Type 'CButtonLib.CButton' is not defined. When I add the button to a form, it appears okay. I can change its properties and it shows up in the code windows and in the object browser. But as soon as I try to run it and it throws the errors, it no longer appears in the object browser. References in the code window lose their intellisense.
Things I've tried include:
Copying the DLL to the project's debug and release folders and loading them into the toolbox from there.
Removing it from the toolbox altogether and just adding a reference then copying and pasting a button directly from the first project.
Copying in a form with a CButton on it from the first project.
Scouring the internet for answers
Swearing at the computer.
Nothing seems to work and I've now spent over a day trying to solve this.
I never did get to the bottom of this. In the end I simply had to recreate the entire custom control project using a different name. I suspect the way I added the original project to the toolbox of a different program – as opposed to adding it within the test project it came with – may have had something to do with it, but that's just a guess. Anyway, I can amend and update the new control without problem now, so all's well that ends well. :-)