We Keep Coding

Using a Form in a separate Project [closed]

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
Has anyone successfully been able to use a form created in one project in another with VS2015?
I have created many forms that I usually need to include in most of my projects, however whenever I try to add them to the new project I can never seem to get them to work.
I would like to add them to a separate project, with their code and designer/image references etc, but I have only been successful in adding the form with code no resources or designer.
Instead I am currently having to manually re-create the same form in a new project and copy and paste and reset all the controls and labels and what not in the newer solution.
In the past I used to do it like this guy did: https://www.youtube.com/watch?v=FPBMoibAmU0 But it doesn't seem to work with VS2015?
Surely there's a simple way to do this? My way works but it's very time consuming and I think unnecessary.
So what I used to do in the past: Copy the form1.Designer.cs, form1.cs into the new solutions directory, then in the new solution, right-click the project properties, add existing file and browse and select the two files and click OK.

Yes, people re-use code all the time, this question is coming from a fundamental misunderstanding about how code and projects work. Code intended to be shared should be created in a shared project or shared/distributed library.
Using a distributed library:
Create a class library (.dll)
Add a reference to System.Windows.Forms
Define any code, forms, resources that are intended to be re-used here.
Compile library and retrieve .dll file.
Copy .dll file into your new project and add a reference to it.
Use the form.
This is essentially how the nuget package manager works except it handles managing the physical .dll files and adding of references automatically. If you will be the only consumer of this and you don't intend to check your source code into a source control server (git, tfs, svn, etc) then you could also store this dll only in a single location (your documents folder, etc) so updating it is easier.
If you want to be able to make changes to the original source code in all the projects that use the form, you can instead add the original shared lib project to your new VS solution by right clicking on your solution, clicking add existing project, and navigating to the csproj file of your library project.

Wow I finally worked it out,
To add a existing form of another project to current:
Right-click the Project Properties in Solution Explorer.
Click "Add".
Click "Existing Item".
Browse only for the "Form1.cs" and select it, Click "OK".
Right click the added "Form1.cs" and select "View Code".
Look at top for "namespace", highlight the actual namespace eg: "namespace Form1", so highlight "Form1".
Right-click highlighted namespace and select "Rename...".
A box appears, tick "Include Comments", "Include Strings", then type the new name in(with still the Rename box visible) and Click "OK".
Now just add the resource files to the current project.

Assigning an image to the composite custom control c# VS .NET 2013

The problem concerns Windows Forms.
I have no idea how to do it. I've tried following:
1) Add a Bitmap (CarControl.bmp) do the solution, then set BuildAction to Embedded Resource and add the ToolBoxBitmapAttribute like:
[ToolboxBitmap(typeof(CarControl),"CarControl")]
2) Going into Properties, then in Resources section I've added some images. Still doesn't work.
Can anybody help?

Naming is very important, otherwise it does not work.
[ToolboxBitmap(typeof(CarControl), "Resources.CarControl.png")]
Another important note:
If you open the solution of your CarControl you will always see the default gear icons for the controls of your actual build. But if you make a build and you add the controls of this (released) library to the Toolbox either by drag-and-dropping the dll or by Right click/Choose Items..., then the icon will appear.
If you did everything well, you will able to find the embedded resource in the compiled .dll when you open it with Reflector or other disassembler tool. The following example is from System.dll:
You should find a <DefaultNamespace of your project>.<Your resources folder>.CarControl.png here.

Why won't the debugger update?

Ive had this problem multiple times and it ruins my projects, I make some changes, like say I have a button in the top left corner of the form and move it to the top right corner, then I press debug but nothing happens to the form, it doesn't change the button is still in the top left-hand corner instead of the top right, and it also doesn't except any new code, its like it saved the project right there and won't move on. Does any one know why or had this problem before?
Please, Help!!!!
Additional Details:
Compiler: Microsoft Visual C# 2008 Express Edition
I once fixed this problem by rebuilding the solution, but its never worked again.

Hey, I got it fixed, I right clicked Form1 in the solution explorer, clicked properties and change the Build Action to none then back to Compile and it seems to be working.

In the Visual Studio settings under Projects and Solutions->Build and Run change the option On Run, when projects are out of date: from Never Build to Always Build
Tools > Options > Projects and Solutions > Build and Run > On Run, when projects are out of date: "Always Build"

In addition to #SwDevMan81's answer with whom I agree, I would say that setting both the output and reference paths may help avoid such behaviour for class libraries. For instance, your application references a class library that you are currently writing, and you perform some changes to this referenced library, but the changes don't show.
What happens is that the compiler will copy localy (to the project's output directory) thereferenced DLL and as long as it is there, it won't get updated. You may verify it by clicking right on the referenced assembly, then clicking Properties. Look at the Filepath property. If you see it doesn't match your actual filepath, then you will have to make sure to set the reference path accordingly in the project properties, then removing then removing the actual reference to add it where the actual build is, that is, where your class library output folder is set. So, whenever you regenerate your class library, your application gets the update automatically. Here's an example:
Application Project references : The ClassLibrary1.dll assembly.
Once you will generate your application, the ClassLibrary1.dll file will be copied to your application output directory. Let's suppose C:\Open\Projects\ApplicationProject1\Debug\bin. So, this directory will now contain the ClassLibrary1.dll file.
You rewrite a method to behave completely differently;
You regenerate the ClassLibrary1 assembly;
You rerun your application (remember that the file already exists!);
Ends up wondering why the changes didn't take effect? That is because your application referenced the cached assembly within its Debug\bin folder.
To workaround:
Remove the assembly reference from your application project;
Go to the project's properties and click the Reference Path tab;
Browse to your ClassLibrary1 output folder, then open it;
Your Reference Path property is now set for this library, then re-add the ClassLibrary1 assembly to your application project;
Run once, stop running, and see if the Path property of your referenced assembly is still the same as the one in the project's Reference Path property;
You're done (if everything worked fine).
C:\Open\Projects\ClassLibrary1\Debug\bin\ClassLibrary1.dll
In the end, this might be the cause of your problem if your GUI Forms are part of a class library, and the solution I described should work.

SwDevMan81 and Tanner's answers didn't work for me.
However,
Build > Rebuild Solution
... did!

Had The Same issue. Build > Rebuild Solution also worked for me

What could cause Visual Studio / C# error MSB3105: Duplicate resources

While working on an existing project I suddenly got the following error when trying to compile the solution:
error MSB3105: The item "[filename]" was specified more than once in the "Resources" parameter. Duplicate items are not supported by the "Resources" parameter.
Now, as far as I'm aware, I did not make any change to the project that affects the resources. Also I have checked each and every file within the project, but there is no duplicate reference anywhere to this file.
Now I already found some forum entries regarding this error:
1) Open the .csproj file and remove the duplicate reference. [Tried this, but I cannot find any duplicates in it]
2) In a 'partial class' project, move everything to a single class. [ Could try this, but the project has been split up into partial classes since the start, and I do not want to change this just because of the error ]
So what else could cause this ?

Did you try showing all files in the Solution Explorer? You could have a duplicate .rsx file somewhere in there.

I found the answer in .NET forum posting by Roy Green, and Theresa was right after all, though I did not recognize it.
If you have your main form class split up into partial classes, the partial sections end up in the solution explorer as separate items. And if you double click on them they show up in the designer mode as a normal form. But if you (accidentally) drop a control on these forms, Visual Studio creates a new .resx file and a InitializeComponent routine for it. But since this form is actually just part of the Main Form class it leads to the 'duplicate resources' error. And there is no other solution but to remove the InitializeComponent routine and delete the .resx file by hand.

Be sure that under yourForm.cs no duplicate resources are defined (.resx). If you renamed your Form, remove the old resource because the new one during compile will be created with the new name.

I just made the same mistake. Delete the mainform.designer.vb, then I restored it again from the recycle bin, and found this error message when compiling.
I try to search on google and someone suggested to check on .vbproj. Did that and found a duplicate on some line.

I had this as well, in VB. There is the "real form" file frmMain, and then I had created new class files and modified them to be Partial Public Class frmMain. For example, I have an ImportFromExcel.vb Partial Class file (I didn't want to clutter up the frmMain.vb with the rather complicated Excel import code.)
Everything worked fine until I decided I wanted to use an OpenFileDialog in the Sub ImportFromExcel. I dragged the OFD from the toolbox over to the Designer view of the ImportFromExcel file. (I have no idea why this view exists, if you can't do anything with it!) But at any rate... dragging the OFD to the Partial Class Designer created an ImportFromExcel.resx file. The drag/drop operation also created an InitializeComponent sub in ImportFromExcel, which is redundant and shows an error -- easily corrected with a little editing.
Ultimately, I chose to not use the dragged resource, but localized the code in the ImportFromExcel.vb file.
All you really have to do is right-click the ImportFromExcel.resx file, and choose Delete. Everything else seems to "fix itself", and it builds fine now.

In my case, this problem happened because a file had the same name but not the same case in the GIT repository.
For example MyFile.cs and myFile.cs.
If you do a checkout on windows, one of the files is overwritten by the other (no message, no warning). So, it is compiling, and we don't notice anything. But if you try to compile on Linux (with .NET Core) both files are present, and there is this error at compile time.

How do I access the Properties namespace from within a console app?

I am trying to store/retrieve a value that is stored in the Application Settings. From within my console application I can not seem to access the Properties.Setting namespace. My web surfing has revealed that a little more work might be needed to do this from within a Console application. How does one do this?
string test = Properties.Settings.Default.MyString;
Thanks!

By default there is no Settings file in a Console application. However, you can add one simply by right-clicking your project in the solution explorer, choosing "Properties" and then in the resulting window, click the "Settings" tab.
There should be a link saying "Click here to create a default settings file". Once that's created, you're off to the races.

Ensure the namespace of the class you're using is the default namespace of your project.
2.then you cna use
string s = Properties.Settings.Default.THENAMEINSETTINGS;
.

So.. Once I created my Settings.settings file in the project that is saving the property I ran into the issue of how to access these properties from another project in the same solution. The settings object is sealed so you have to use a little trickery to gain access to the property values in another project. I found my solution here:
http://blog.decarufel.net/2007/10/getting-access-to-settings-in-another.html
Basically you create a link file to the Settings.Designer.cs file in the project where you are trying to retrieve the values.
I hope this helps someone with a similar issue.
-Nick