I built a class library exporting two custom controls using c#. This class library depends on some references, which are duly copied into the bin\Debug directory on build (of a solution using the custom controls) as long as I add only the controls DLL as reference. So far, so good.
If I now add the controls from that output directory into the toolbox and place one on an empty form in the designer, visual studio crashes. If I debug from the custom control solution like so http://msdn.microsoft.com/en-us/library/5ytx0z24(VS.80).aspx, I can see the IO exception that one of the referenced DLLs cannot be found.
So, is there a reasonably elegant way of placing the dependencies for the designer to find them? I tried fiddling with the reference paths in the project settings, but to no avail. I would prefer to avoid setting system-wide paths and installing/registering the control every time I change a bit of code.
Why don't you just reference the project as a whole rather than manually copying in the dll? If you have a good reason for this then fine, but it seems as though you are asking a question which doesn't need to be asked! :P
Related
An .xaml image location in a secondary reference is not becoming the correct resource location during runtime, it refers to the primary reference resources folder instead. How can I change this?
Background -
I have a solution with several projects. The important three projects here are
a WPF project which builds as a class library
a default class
library
a console app for testing
The WPF project has a .png image in its resources. In the MainWindow created it's called via:
<ImageBrush
ImageSource="pack://siteoforigin:,,,/Resources/MyDemoImage.png"
Stretch="Uniform"/>
When I run an instance of the WPF window directly through the console app, it works fine. The resource reference becomes during runtime:
C:\Users\me.me\Documents\Visual Studio 2015\Projects\sol\
WPFProjectName\
bin\Resources\MyDemoImage.png
But if I create a reference to the WPF project within the class library project then call an instance of the class library, the address becomes
C:\Users\me.me\Documents\Visual Studio 2015\Projects\sol\
ClassLibraryName\
bin\Resources\MyDemoImage.png
So this "pack" address becomes a reference to the class library resources rather than the WPF project resources folder.
Now, I think I could simply add the resource to that middle-man class library too, but I'm wondering if there's some correct way to reference a "secondary" resource, so I only have to add images once?
By the way, the error I get when I try to compile this is System.Windows.Baml2006.TypeConverterMarkup - I've found answers regarding this but tried what they say to no avail (mark image as copy always etc.)
Change
pack://siteoforigin:,,,/Resources/MyDemoImage.png
to
pack://application:,,,/AssemblyName;component/Resources/MyDemoImage.png
Thanks to #Clemens for his advice. This worked great.
I just wanted to answer and share a bit of other frustration-gathered knowledge I found while experimenting with this.
Using pack://application:,,,/AssemblyName;component/Resources/MyDemoImage.png worked great for me for my first image. I then had loads of trouble trying to do the same thing for a 2nd/ 3rd image. It kept compiling ok but on runtime the inner exceptions were throwing out that it couldn't find "resources/mydemoimage.png"
The reason for this was due to the BuildAction on the images. I'd been playing with the different types, some of which worked for my local copy (e.g. setting BuildAction to Embedded Resource actually fixed the initial issue I was having) BUT for the pack://app... to work, compile and then carry through to install and be instanced in another application (e.g. VBA in Excel)...
The BuildAction MUST be Resource
I was extremely lucky that I'd set this by chance before trying Clemens' answer because if I hadn't I would have assumed it just didn't work! But it does!
I have a need to identify if I'm referencing a specific assembly in my project/solution. I've not found an easy way to do this (I want to do it at design time and not run time if possible).
Seems this should be easy, but I'm not finding a way in VS, directly. Ideally, if I could see what/where I'm referencing (assuming that I am) would be great, too, so I can remove such references from my code.
Simply searching for "Assembly." in my code turns up nothing, now, for example.
A concrete example is in order: I want to know if I use anything in System.Reflection.Assembly. And I'd like to find the code that does it (in my source) if I do.
Do you want something like Assembly.GetReferencedAssemblies Method ?
http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getreferencedassemblies(v=vs.110).aspx
In Visual Studio (almost all versions) open the Solution Explorer window the second "folder" is the References section. If you expand that you'll be able to see the referenced assemblies.
Image from robowiki
I created a brand new blank Visual Studio 2010 solution, and added an existing C# Project to it. I built the solution and it compiled correctly.
But when I go the solution folder, I see that the imported C# project is not physically in that folder. It seems it only references the project to wherever it is.
Is this intended? Should I even worry about this?
How can I create a physical import, meaning the project is copied to the solution folder?
How can I create a physical import, meaning the project is copied to the solution folder?
If you want to do this, copy the project to the solution (outside of VS), then add the local copy directly.
The default behavior allows you to share a project between two solutions. This is occasionally useful (if handled with care).
'How do I create a physical import?'
You don't - you're adding a project to the solution which will always result in referencing it in-place. In order to structure your solution you need to copy or move the existing project to the desired folder, created any desired Solution Folders to match the physical structure and then Add existing project as needs be.
The other alternative is to Add new project and then copy all of your project data over from the existing one but this will be prone to errors at some levels.
Adding an existing project always makes reference to the original. That makes sense in a lot of cases. If you want to use the project in a number of solutions and you want to make sure that they are always using the same version then you have the choice to either just reference the compiled library or have it available in each solution. If you do have it available in each solution then the risk is that you will make some mod of it in one solution that breaks the others. I am pretty good at doing this!
As mentioned already if you want to modify that project and don't mind if it gets out of sync with other versions of it then you need to copy it into your solution folder and then add it from there.
The version control software I use pretty much forces me to do that as it does not like code that is not located inside the solution tree.
It's not code-related but IDE related. I'm working on a .NET solution with about 35 different projects. These projects need to be re-organized into a new folder structure. Why? Because about 10 of those will be removed and the rest will be divided in more logical units.
One way to do this is by creating a new solution, Drag&Drop the projects into a new folder tree within the Windows explorer and then just add them to the new solution.
To be honest, that sounds dumb!
Is there a way to just move projects into different folders from within the IDE? I've tried to "save as" the projects but the IDE won't accept a different folder.
It's irritating but because there have been a few wrong choices in folder names, I'm now stuck with those names.
Example: Right now I have a project main folder which contains child folders named "Client", "Server", "Business", "Database" and whatever more. Within those child folders, there are more child folders, each a three-digit number. Within each numbered folder there's a project which is named in some logical way, like Company.Business.Customers with additional logic within this project.
The problem is that not all projects now follow this naming convention and I consider it obsolete.
A project like Company.Business.Customers should just be in a folder named Company.Business.Customers in the project root so it's easier to recognize. The name already makes it clear that it's a business class for this project. The clear division within client classes, business classes and whatever more just needs to be arranged within the solution, but I want to flatten the file structure. (And remove some obsolete projects.) Basically, I'm not refactoring, I'm just cleaning up.
VS2008 doesn't seem to have such an option, though...
Fire up notepad.exe and open the .sln file. And start Windows Explorer, navigate to the solution directory. Observe how the .sln file content matches the solution structure. Edit the entries, make the corresponding change with Explorer. Backup first.
I don't think there's an easy answer here. Your main problem is going to be that Visual Studio (or .NET) doesn't care if you have classes that belong to a different root namespace sitting in a project.
So if you have a project called Project.BusinessObjects and another project called Project.DataObjects there is nothing stopping you from putting a class called Project.BusinessObjects.User into the Project.DataObjects project.
I don't know of any way of doing all of this without a lot of manual work. Resharper will help quite a bit if you use the 'namespace rename' feature, but you're still gonna end up with a lot of grunt work.
Also, be VERY wary of doing this in conjunction with version control systems. You have to know your version control system really well to know how it's going to react to such major refactoring.
Other than that, what you are describing doing is not all that difficult. You do have to edit the solution files and maybe the project files by hand, and you might need to remove a project from a solution and add it again when it's under the right directory.
I would make a backup, and then refactor away. I think it is a mistake to think that you can do everything you need from the IDE, though. And if you do what you describe from the IDE in a source control system that uses the old Visual SourceSafe API, you will certianly (guaranteed) mess up your bindings, that API is just not made for moving (or renaming, for that matter) files around in the way you describe. The best way to do this under that scenario is to remove all source control bindings and then re-add the reorganized solution back in.
It's not that difficult, you just have to prepare (do a backup) and experiment until you get it right.
I don't think there's any way to do this from within Visual Studio, and as #gmagana points out it's going to be very difficult to do if the files are under version control.
However, it is possible to do it manually.
Start by creating the new, desired folder structure - ignore the .csproj files and solution files for now, and more the .cs files you're interested in into the new structure.
Now, fire up Visual Studio, and create a new, empty project. If you have different types of projects, you might want to create one new, empty project for each type. This will leave you with an empty .csproj file, and a .sln file with just one project.
Copy the empty project file to where they're needed, and rename them as needed. You can edit them and change the Assembly name and default namespace if you want, or wait until you're done and change the settings with Visual Studio.
Finally, edit the .sln file, and remove the Project section. Copy the empty .sln file to where you want it, and open it up in Visual Studio. Now go and add each of your existing projects to the new solution.
Within each project, click the "show all" button, and start including all the files you've copied into the project structure. Resolve missing dependencies, change the namespaces and assembly names for the project, and make sure that the code files don't specify a namespace you don't want. Repeat until done.
Once you get the new solution to build, it will be helpful to open up the DLLs in Reflector in order to ensure that you haven't missed any namespace declarations in the code file - if you're trying to get to a point where there's a 1-1 correspondence between the DLL and the namespace, or even ensuring that no namespaces are split between DLLs, Reflector is your friend.
Good luck.
I've used the following solution to solve my problem:
I started with a new, empty solution in a new folder.
For every project that needed to be moved, I used the Windows explorer to create a child folder in the solution folder, this time with the proper name.
I copied the projects from their original location to their new folders.
I added all the (moved) existing projects from their new locations.
In the Solution Manager, I renamed the projects to a better name.
I fixed the project properties and other settings for all projects.
This did clean up the whole project quite nicely. I then added the whole project to Vault (Version Control System) and once it was in the VSS, I deleted the folder again (actually, just renamed it first) and retrieved it back from the VSS system so any obsolete binaries and other garbage was gone too.
It's a lot of work, but the result turned out exactly what it needed.
I'm new to visual studio, coming from Delphi.
I have a directory tree full of .cs files (root is \Common).
I also have a directory tree full of Applications (root is \Applications)
Finally, I've got a tree full of Assemblies (root is \Assemblies)
I'd like to keep my .cs files in the Common tree and all the environment voodoo (solutions, projects, settings, metadata, debug data, bin, etc.) in the Assmblies tree. So, for a simple example, I've got an assembly called PdMagic.Common.Math.dll. The Solution and project is located in \Assemblies\Common\Math. All of its source (.cs) files are in \Common\Math. (matrix.cs, trig.cs, mathtypes.cs, mathfuncs.cs, stats.cs, etc.)
When I use Add Existing Item to add matrix.cs to my project, a copy of it is added to the \Assemblies\Common\Math folder. I just want to reference it. I don't want multiple copies laying around. I've tried Add Existing Item, and used the drop down to "Add link" rather than just "Add", and that seems to do what I want.
Question: What is the "best practice" for this sort of thing? Do most people just put those .cs files all in the same folder as the project? Why isn't "Add link" the default?
Thanks!
You can just use Add As Link by clicking on the little down arrow to the right of the add button from Add-->Existing Item command...
Whilst I realise this is not in an answer to the original question (which regards best practices), I present this answer in order to save the time of others who have been directed here by the misleading title of this question.
The "best practice" in this case, is to not fight the tool. It allows you to do what you want, but you'll get more work done and be able to focus on code if you just let the IDE organize your project for you.
I would create an empty solution project called PdMagic.Common
This will give you a file structure like
PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln
then I generally add a src and libs folder (via the file system, not VS)
inside the libs folder, i would place all my third party dependencies, and the src folder would hold all of my projects
PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln
PdMagic.Common\libs
PdMagic.Common\libs\nunit
PdMagic.Common\src
Next, in Visual Studio, I would right click on the Solution I just created, and click "Add -> New Project", I would specify that I wanted it created in the \src folder and call it PdMagic.Common.Math
Now my folder structure would look like this
PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln
PdMagic.Common\libs
PdMagic.Common\libs\nunit
PdMagic.Common\src
PdMagic.Common\src\PdMagic.Common.Math
PdMagic.Common\src\PdMagic.Common.Math\PdMagic.Common.Math.csproj
PdMagic.Common\src\PdMagic.Common.Math\Class1.cs
Then, as you add classes to your PdMagic.Common.Math project, they will go in the folder with the project file. This is how the IDE has the opinion we should work, and I think most developers go with it because trying to get any other layout on the file system would require too much fighting with the IDE. I know it can be hard to come from a different convention, and you instinctively want the same conventions in the new environment. However, if you stick with the conventions, (right or wrong in your opinion) you'll get more done because you won't be trying to force the IDE to do things the way you think they should be done.
I think that the 'best practice' is to have those 'common' routines into an assembly that you can reference instead of pulling the source files into a bunch of different projects. You could add it as a pre-built assembly with "Add reference..." or by including a project for that assembly and adding a reference to the project (also done inthe "Add reference..." dialog).
This is one of those things that seems like a bit of work to set up initially (and it may be), but it generally pays off in the long run.
If you want to "reference" matrix.cs in your project, don't use Add Existing Item, create a reference ("Add Reference") to the class library or object that matrix.cs is a part of. If you don't want (or can't use) the library or object that matrix.cs is part of, then the Add Link is how you would get to it, but seriously I've never used that particular feature.
None of the developers I have ever worked with in .NET isolate their .cs files in separate folders. The only kind of segregation like that that I have seen as a practice is in MVC, where the models, views and controllers are in their own folders.
Because you want to reference matrix.cs in the project, dont just use AddExistigItem, create a new referene to the class.
VS has some useful extensions for this:
http://vscommands.com
and ProjectsLinker: http://visualstudiogallery.msdn.microsoft.com/5e730577-d11c-4f2e-8e2b-cbb87f76c044?SRC=VSIDE
and SourceShare: http://visualstudiogallery.msdn.microsoft.com/aa5d54dd-0b05-4689-ad2f-634e86de327f?SRC=VSIDE
In Visual Studio 2019 it is:
Right click on a project
Add
Existing item
Select file
Expand menu next to Add
Add As Link