C# Visual Studio using the wrong .exe icon - c#

I first added "icon1.ico" to my project under Properties->Application. When I build it my .exe had "icon1". After this I decided to change the icon to "icon2.ico", which I added in the same way and selected. The little icon beside the dropdown menu shows "icon2". However, when I build the project it still uses the old "icon1".
Then I removed the old icon from the project, and rebuilt. Still the same old icon.
I then changed to the "default icon" in the dropdown (the dropdown only shows "icon2" and (default)) and rebuilt. The exe then has the default icon. Changing back again to "icon2", and the exe has got "icon1", dispite it not being in the project anymore.
How can this be?

I managed to find what was wrong.
In my Solution I had 3 projects. For some reason, dispite being seleted as the startup project, all my cleaning and rebuilding attempt seemed not to affect the project with the wrong icon (this includes deleting the bin folder), the only project that was being build was one of the other two (the output still said 3 build successfull, with 0 up to date).
What solved it was to right click on the specific project and select rebuild, which applied the correct icon.

Related

How to rename "Primary output from MyProject (Active)" and .exe

I am brand new to building and deploying Windows Forms applications, so new that I'm not even sure "build" and "deploy" are the correct terms. I read this excellent guide to creating an installer for my application, and I mimicked it almost exactly.
I have a winform project UmfExtract and a setup project UmfExtractSetup that installs UmfExtract . After installation, however, on Windows 10, an icon appears at the top of the start menu, under Recently Added: "Shortcut to Primary output from UmfExtract (Active)." I want to rename that to just "Shortcut to UmfExtract" or just "UmfExtract." Additionally, in the installation directory, the .exe and the .exe.config are the same as the original name of my project when I first created it, PythonExecuter. How do I change PythonExecuter.exe to UmfExtract.exe? Elsewhere on the user's computer, the application is named correctly. On the desktop, the shortcut icon says "UmfExtract," which is correct.
In all my research on this, people have said to change the Assembly name. I have done that. The Assembly name is UmfExtract:
I looked into the Outputs property of the Primary output object:
The AssemblyTitle and AssemblyProduct in AssemblyInfo.cs have been changed to UmfExtract:
What else could I possibly be missing? Could I perhaps accidentally be installing an older build of my project? I right-click on each project in the Solution Explorer and click Build (while the Debug/Release drop down box in Visual Studio is set to Release), then I navigate to the Setup project on my local machine and go to \Release\UmfExtractSetup.msi. I imagine that .msi file is updated/overwritten to the new information each time I Build the projects. Could it be that I'm building wrong?
I'm not 100% sure what was wrong, but the problem has been fixed. I believe the error was in the build process. I believe I was installing an old build of the project. I clicked Build > Clean Solution from the menu bar, then Build > Build Solution. I also right-clicked the UmfExtract project and then clicked Clean, then Build, and I also right-clicked the UmfExtractSetup project and then clicked Build (there was no Clean option in the right-click menu for the Setup project).

Change dll References in Visual Studio

I'm trying to create a Monogame Project in Visual Studio 2012. Monogame itself is installed correctly, I've cloned one of my older projects from github and it compiles fine.
But if I create a new project in Visual Studio the .dll references are wrong. There is a build error that complains about not finding SDL.dll . There is the SDL.dll reference in my project outline and it indeed points to the wrong file:
This path "C:\Users\lhk\Program Files..." does not exist. Windows doesn't store Program files in its "Users" folder.
I opened the explorer and opened the very same path without "Users\lhk\" and the .dll is found.
Then I checked my older project again. The same SDL.dll is referenced in the Visual Studio solution but the path is the correct one. And the older project compiles just fine.
Somehow the Monogame Project template fills in the wrong paths.
Now here's the problem:
I can't edit that reference.
The text is greyed out and not editable and I didn't find the correct settings to change the reference.
Oh, the problem is solved:
I tried drag-and-drop with the dll.
So far Visal Studio always complained that there is an existing file with the same name.
I tried to "cut" the wrong .dll but that only made its icon slightly transparent. The new .dll still couldn't be added.
Turns out that the ENTF key can do what cutting can't.
I'm afraid I never got the idea that I could delete it with ENTF after cutting didn't work. Now its gone.
I dragged the new dll over to the project.
Compiles fine
Apparently you can just drag and drop references to a project.
At first I thought this wouldn't be possible because the wrong .dll just couldn't be deleted. I tried to "cut" it from the project but it just changed the color of its icon and persisted.
With the old .dll still intact the new one couldn't be added.
I'm afraid the solution is extremely simple. You can just remove this reference by pressing "ENTF" - it's rather embarrassing. But I never thought this would work after cutting had no effect.
With the old reference having been removed you can indeed drag and drop the new one.
The project compiles fine.
What I did is create a path on the drive and put the sdl.dll file there. So whenever I make a project Visual Studio finds it.

C# - Visual Studio project build

I have the following problem.
I made an application in C# (using Visual Studio 2010). Everything worked fine.
Then I had to make some changes in a "main.cs". Did those... all fine again.
Then I had to make other changes in same file. Did those... cleaned the solution built it. The problem is that when I run/debug/anything the application I get the same result as I did before I made the changes. I even tried to break the code (called a random function that didn't exist, used wrong syntax), but the result was the same "Build successful" and the old version.
Is there some kind of cacheing mechanism or something? How do I get rid of this problem?
I added prints for the "compile" solution... I can't find the build property.
Try deleting the bin and obj directories in the Visual Studio project directory. The obj directory contains the temporary files used to create the binary while the bin directory contains the binaries for that project. In addition, check if there are any warnings being shown when you build your solution.
I was able to reproduce the same error i.e. build successfully even though the file has not been compiled. The Build Action of the file had not been set to Compile.
The correct Build Action for a code file (main.cs) would be Compile.
According the updated question the file properties does not have the compile option
The reason for this is that the file (main.cs) has not been included in the project, but the "Show all files" button is "on" in the Solution Explorer. The file has not been included in the project (hence not compiled) and the file icon is greyed out in Solution Explorer.
To include this file in the project, right click on add existing item to the project (see following image). In the subsequent dialog select the file (main.cs) and click on the add button.
This should solve your problem.
In future, it is best to keep the "Show All Files" button as "off" to avoid confusion.
Is it possible you have selected the build and run last successful version? Check out my answer to something similar here. If the changes you made broke something and you had checked the boxes and hit yes to the dialog boxes in my answer below then that's most likely the issue.
Cannot see changes I make when I run my application in Visual Studio
Make a backup of your solution.
Delete the .cs files from within the solution explorer. If your program compiles and runs, than you are linked to source folders and not actually using the one in your solution.
I doubt this is it, but worth a try. The other things that came to mind you have already eliminated out with the previous answers.

"A project with an Output type of Class Library cannot be started directly"

I downloaded a C# project and I wish to debug the project to see how an algorithm implementation works.
The project has come in a Folder, inside this folder there are -
.sln file and
a folder which has source files and a .csproj file.
I installed Visual Studio and opened the .sln file present in the main folder. I built the project successfully, but when I try to debug the project I get this message:
A project with an Output type of Class Library cannot be started directly In order to debug this project, add an executable project to this solution which references the library project. Set the executable project as the startup project.
The strange part is that I don't see a main function anywhere.
What should I do to get round this hiccup?
The project you have downloaded compiles into a dll assembly and provide a set of classes with implemented functionality.
You should add to your solution a new project with Output Type of either Console Application or Windows Application (VS Add Project wizard will offer you different templates of Projects).
In the newly added project, you can implement logic to test your Class Library.
Output type of the project you can find and change by the following steps:
Right click on project in Solution Explorer -> Properties.
In opened tab with properties select Application and there will be ComboBox marked with Output Type label.
Just right click on the Project Solution
A window pops up.
Expand the common Properties.
Select Start Up Project
In there on right hand side Select radio button with Single Startup Project
Select your Project in there and apply.
That's it. Now save and build your project. Run the project to see the output.
This was the solution that worked for me since I couldn't find 'Common Properties' option.
Select your topmost level project in Solution Explorer.
Go to Project, and in contextual menu Set as StartUp Project.
See also: A project with an Output type of Class Library cannot be started directly
Just needs to go:
Solution Explorer-->Go to Properties --->change(Single Startup project) from.dll to .web
Then try to debug it.
Surely your problem will be solved.
The strange part is that I don't see a main function anywhere.
That is exactly your problem. The project merely creates a DLL. It has no executable to run.
You will need to add a second project, which is an executable which references the other project, and calls something in it.
1) Right Click on **Solution Explorer**
2) Go to the **Properties**
3) Expand **Common Properties**
4) Select **Start Up Project**
5) click the radio button (**Single Start_up Project**)
6) select your Project name
7) Then Debug Your project
Right Click on "Solution Explorer" -> "Properties"
Expand "Common Properties"
Select "Start Up Project"
click the radio button "Single Start_up Project"
select your Project name from the drop down list.
If still not working after the above steps, then try this.
Expand solutions explorer.
Right click on project name -> "Properties"
Go to "Application" tab
Select "Output type"
From the drop down list select the appropriate type according to your application.
"Windows application" or
"Console application"
Then save (ctrl + S)
Try debugging (F5)
You'll need some kind of app (Console Apps are my favorite for debugging, but a WinForm will do) which uses your Class Library. Just add a new project (in the same solution) of a Console Application or Windows Forms Application, and add a reference to your current project. Once you've done that, make any calls you need, set your break points, and go to town.
I had a similar issue when trying to use the Experimental Instance of Visual Studio 2013. This was for a vsix project (Creating Snippets).
Solution was:
Right Click Project in Solution Explorer > Properties > Debug
Setting the Start Action to "Start external program" and using the following path:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
This option was set to "Start project" which won't work for the application output type Class Library, which caused that same error.
Note: Yours may differ depending on how you installed VS.
Error solutions is that you have already open your project but by mistake you have selected another class library .. that's reason this error is showing ... so what u need to do you u just select u r project then right click on u r project
after right click u can see the list box and select the "Set as start up project " option .
Accepted answer works if your solution has a project that compiles to an exe. If your solution does not have any projects that compile to an exe, then you have to use 'Start external program'.
VS2019 instructions:
right click -> properties on the main solution
debug, start external program, and add command line arguments
VS2022 instructions:
right click -> properties on the main solution
scroll down to Debug
Debug > General > Open debug launch profiles UI
left click the 'new' icon in the top left, select 'executable'
fill it out as per VS2019 (pick the exe and add command line arguments)
when clicking the start button, first select the profile you made
Suppose you have multiple project in the solution. Select the project that you want to view in browser and select 'Set as StartUp Project'. In your multiple project soln which was the main, the visual studio was unable to identify. this was the main problem.
You can right click the Class Library project and from the drop-down choose Initialize Interactive C# which will load your project context and you can work it in the interactive session.
In my case, the cause was that one of my projects in the solution wasn't loaded. The reason it couldn't load properly was that the file path length of one of the files was too long. Upon deleting this long file, I could reload the project, and build the solution.
If the question involves an Azure project, make sure you have the "Azure development" tool set installed, or when you go to run a solution you may get this same error.
Tools > Get Tools and Features... > Tick the box next to Azure development > Click install
None of the answers provided above helped me resolve this error, this is what resolved the issue for me.
Right click on the solution and select "Properties", which is in my case "Sintctech.Data".
Select the section called "Application".
Check what you have selected as your output type. If it is "Windows Application", change it to "Console Appication".
Rebuild and the problem should be fixed.

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

Categories