I was updating project properties in VS2015 (like preprocessor, folders, etc) by right-clicking on the project, then project properties. But since a day or 2, the project window is missing almost all entries:
How can I recover missing entries ?
Fount it, I actually changed the language of VS2015 after creating the projects. Reverting back to previous language makes it work again.
Related
I am writing a very basic library in VB.NET
The library just contains classes and modules.
Now in built output I see this files
Application.Designer.vb
Application.myapp
AssemblyInfo.vb
Resources.Designer.vb
Resources.resx
Settings.Designer.vb
Settings.settings
Since I've seen other libraries with only AssemblyInfo.vb file, I was wondering if I can delete the rest.
What is the minimum of files I need here for the lib to work correctly, since I don't have any ressource or setting?
All the files you listed are necessary for a vb.net library project. And these files are generated (in My Project folder) when the project created not the build output files. So you need to keep all the files you listed in order to develop and build your project locally.
And for the files of build output, you can add these files in .gitignore.
When you create a project in VS, you select a predefined template that dictates what gets created. People often become accustomed to seeing the superfluous objects that a given template creates and assume that those objects are mandatory and must be there, However, much of it is not needed.
There is also the Empty Project template (the exact name of this template varies depending on the VS version used).
In VS2017, selection of the template would look like this:
This is a bare-bones project and the Solution Explorer will look like this:
As you can see, there are no pre-loaded references. You will need to add them yourself. About the only thing defined in this template is that you are using the VB language; This project starts out as a WinForm type, so go to the Project Properties->Application tab and change the "Application type" to "Class Library" since you want to create a library.
You may find it useful to start with an Empty Project and add the stuff you normally use and then export the project as new template (in VS2017: Project Menu->Export Template). For more on creating termplates, see: Creating Project and Item Templates
Edit: I just realized that I did not answer your real question about deleting the unused items. I just did a test case and deleted the items under MyProject. I received an error on deletion, but doing a clean/rebuild allowed me to proceed without issues. I would recommend that you backup the project before attempting this on an existing project, but I saw no long term issues in deleting unneeded objects from MyProject.
We have a VB.NET Windows Forms Solution developed using the 3.5 framework.
The solution has more than 30 projects (dlls) that are referenced from one to another. We even have some projects separated into N layers too (one for the data Access, other for the business logic, and so on).
Since a time ago the solution does not work properly. When we start Visual Studio (2008), it shows hundreds of errors. The vast majority are:
"Type 'XXXX' is not defined.
And after doing some "clean" + several "build" we are able to get the binaries.
Anyone has any idea about what is the problem and how to solve it??
You have a problem with the dependencies, maybe incorrect order or circular reference. For example this can be one of the scenarios you are suffering:
Project A depends on Project B
Project B depends on Project C
Project C depends no nothing.
You build all projects in this order A,B,C. First time you build A,B fails but C works. Second time A fails but B,C works. Third attempt A,B,C works.
In theory Visual Studio should work out the correct order... but if you have unused dependencies or circular references it fails.
You have to review and clean your dependencies. You can use
nDepend (http://ndepend.com) or similar tool (Resharper, Architecture Explorer in VS2010 Ultimate, etc.) to make a dependency map and then use it to clean your dependencies. You can
find a lot of good tools in this SO question.
Once you review and clean your dependencies it would build at the first attempt.
All you need is to correct your project build order.
First work out what projects depend on what others. The ones that do not depend on anything should go to the top of list and ones that depend on others should go below in order.
Then right-click your solution and select Project Build Order... from the popup menu.
The following dialog box will appear. Set the project build order in correct sequence. Use the Dependencies tab to specify the dependencies correctly.
I have a visual studio solution written using VB.net.
The solution contains 4 projects.
A GUI
A Service
A Settings library
A WiX Setup project
Here's how it used to work.
Last week, I had no shared settings library, and all was fine. But, because both the GUI and the Service contained an identical class named ConfigXML.vb (for serializing and deserializing settings), which I was regularly making changes to and copying and pasting between projects, I decided to extract the class into a library project of it's own (3 above).
This week, nothing works!
I added project references to 1. and 2. and things do work the same as they ever did. When I "start debugging" I can see and use the GUI as normal.
However, the problem I have is that when I create and install a new Setup of the solution, both the GUI and the Service fail to start.
I presume that the problem is the settings library is no longer where it was expected to be / hasn't been registered properly, needs to be placed in a directory by the Setup.msi or something similar.
This is my first time doing something like this, so I expect it's an obvious fix that I need.
I gather from the name of that class "...XML.vb" that there is an XML file that lives along side this class on disc. If there is such a file, then you need to add that file to the project and then right click on it go to "Properties" and set the "Copy to Output Directory" to "Copy if Newer"
BACKGROUND:
I'm self-taught in VB.net, having been a VB6 developer for years. I'm now out of the field but I'm making a forms app that I need for my new business. I am using VB2008 Express, and I'll upgrade to later versions when necessary. Because I am self-taught I mostly work from examples and there's a lot about .NET I don't understand.
SITUATION:
I've built a Usercontrol. (A custom datetimepicker which I call "datebox"). Then in my application project, I add it to the toolox, then plunk it on a form. It works great so I use it many times in my project, each time with a various properties. No problem so far.
THE PROBLEM:
Oopsie... Now I realize I want my usercontrol to behave a little differently. I modify its project, keeping it backward-compatible with regard to properties and events. Then I rebuild the control.
Ad you might expect, I find that the project that uses the control is still referencing the old version, which it has placed into its own \debug\ folder. Originally, I had added the control to the toolbox from my "DateBox\bin\Release" folder.
My current process to update my project for the new version is very time-consuming... First I delete every datebox object from every form, then I remove the reference to the datebox control, then I remove it from the toolbox and put it back, (not sure if that step is needed) then I place all of my databox objects back where they belong, (which automatically adds it to the project references) and set each of the properties of each datebox object.
THE SOLUTION????:
Surely, Microsoft must be smarter than I am, so it's GOTTA be possible to just rebuild the user control, then just "suck in the new version" without having to remove and replace each one and reset their properties as desired.
Can I get some guidance on how this can be done?
Assuming that the UserControl is not part of the solution, the approach that we use to to create an Assemblies folder on disk somewhere in the solution hieararchy.
Any external assemblies that we use in any of the solution projects are then copied into this directory and the assemblies are added directly as references. This allows us to use different versions of the assemblies in different projects and not have to worry about accidental updates to either assemblies that we are responsible for or others.
If we need to use the controls at design time, we remove any previous controls from the toolbox and then drag the file(s) from the assemblies folders into the toolbox to ensure we get the right versions.
An iPad project I have been working on has become bloated with a huge number of files. The application is a prototype and we are considering ways to prevent this when we rewrite it.
One of the members of our team suggests dividing all of the components into separate Xcode projects which will be included in a master Xcode project.
Is this a good idea? What are the reasons, if any, to avoid dividing features/components/controls into separate Xcode projects?
You can add a subsidiary project file to a master project file in Xcode. Just choose "Add File" and add it. When Xcode builds the master it will build the subsidiary as well if needed.
I use a similar system. I often break a project into sub projects just so I can focus on and enforce encapsulation. I write the data model first, then add the app delegate, then specific UI elements. I add each project to the next in turn. This also allows me to go back and change things without as much risk of breaking.
Really, a properly designed objective-c app should be easy to decompose into multiple project. Ideally, all the components are so encapsulate that they don't need any others save the data model.
We have put some of the code in its own project, building a framework which we link against at some of the other projects. It's sometimes annoying that you won't see the implementation files of the framework code right away in another project (by cmd+clicking or cmd+shift+D, or whatever you do normally to navigate). Xcode will only show you the header, you'll have to open the other project and find your file there manually. Not a big deal, but if you look up the code often, it will bother you.
A real problem is that you change the scope of some operations. Stuff like "Find in project" will work on a different file set, which might not be what you want sometimes (trying to find where this method is called / key is used in your whole code, or something); well, there remains Finder / find, so it might be okay. Refactoring is not - all the renaming stuff just breaks, as it will change only the code of the current project, but not of projects referencing this one. If you change interfaces often, better avoid splitting up the project.
A good thing is that you will get less conflicts on your .xcodeproj files (if stored in a shared repository) as someone removing a file from project X won't create a conflict with someone else adding a target on project Y, which where previously the same .xcodeproj (not exactly sure this is a conflict case, but there definitely are some).
Now with Xcode4 you can create a workspace and add all your projects there. Only for documentation purpose :)
To view and modify subproject implementation files, you should add the sub projects directly into the main project.
1 step - Drag and drop the .xcode project files to main project.
2 step - Go to main project TARGETS - > Build Phases. Add subproject target in Target Dependencies. You can also add binary files in Link Binary With Libraries.
3 step - Add subproject source path to main projects header search path.
Go to main project - > Build Settings - > Header Search Paths (e.g $(SRCROOT)/../CoconutKit-master/CoconutKit/Sources )
An Xcode project can have any number of build targets within it, and you can arbitrarily group source files into folders. What makes you think that multiple projects are necessary?