I just created a new VB Windows forms project using VS2010. The solution also contains a Fortran DLL project. I've set the platform to x86.
When I pull up the VB project properties it does not list the configuration or the Platform at the top of the properties dialog. This means I can't set the Compile tab Build output path differently for debug or release.
I've created several similar solutions using VS2008 and recently converted them to VS2010 and have not had this problem.
Mike
That is because you are using VS2010 Express and your single project is not in a solution project.
You could manually change the output from your .VBPROJ file with notepad. Inside that file you could do other changes . FOr exemple switching from Debug to Release. You have to restart your VS2010 Express edition to apply the changes (if I am not mistaken and it will be onkly true if you are using the Express Edition)
Related
I am using vs studio 2022 making a vb.net project, it was still beta so I used the default name (WinFormsApp).
after finishing the project I changed the name via solution explorer (changed both solution and project names).
Now when I publish the project it has no problem. However, when I debug from inside the vs studio it runs the last version of the app before changing its name.
In other words now to test any addition to the coding or designing, I have to publish then test on the published version instead of simply clicking 'debug
I checked for assembly names, saved and even built solution and project but still runs an out-datesd version (last version before changing the name)
Thanks for helping :)
I want to write a cross-platform console application in VB.NET using Visual Studio Community Mac 2019 [VSCM2019]. It has to be able to be run on all platforms that dotnet 5.x currently supports.
When I create a new VB.NET console application in VSCM2019 it defaults to NET Frameworks 4.8 or lower. When I try to change that to net5.x in the project properties, net5.x is not offered in the dropdown list despite the fact that I have installed the latest dotnet 5 sdk.
Is it the case that I must select net5.x when creating the project? If so, where is this done for VB.NET console applications?
Whether or not VB.NET is supported or not, I managed to hack it into submission. I created a net5 C# project, renamed the .csproj file to .vbproj and replaced the .cs file with a .vb file. Instead of opening VS via the .sln file, I opened it via the .vbproj file. It compiled and ran and the project properties reflected the change to VB.NET. I then replaced the .sln by saving the project.
I want to store startup settings for my project. When I go to the project Properties/Settings, it's empty except for a link that says, "This project does not have a default settings file. Click here to create one." When I click the link to add one, it says "The system cannot find the file specified. (Exception from HRESULT: 0x80070002." So, how do I add a default settings file?
As mentioned in my comments, this seems to be a bug in VS and ought to be reported to Microsoft. As a temporary workaround, you can actually copy the settings files from a .NET Framework project into a .NET Core project. As far as I can tell from examining various VB and C# projects targeting .NET Framework and .NET Core, the settings files are the same in each case, so there's no issue copying between them. Here's what I did:
Added a VB WinForms app project targeting .NET Framework to the same solution.
Clicked the Show All Files button in the Solution Explorer for both projects.
Expanded the My Project node for both projects.
Dragged the Settings.settings item from the .NET Framework project to the .NET Core project.
It seemed to work as expected after that.
I'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
I'm using Visual Studio 2005 and I have a C++/CLI project I'm using as an interface DLL between a third-party unmanaged library and a C# project.
In this project (as with my C# projects), I'm using a tool called Build Version Increment to automatically increment the version of the project at each build.
The problem is that when the C++/CLI DLL is built, it takes its version information (and other useful details like product name that can be found through right-click > Properties > Details) from a Version Resource. The version incrementing tool I'm using doesn't update this file, so it's sat at v1.0.0.1.
I'd like to know if anyone knows how to automatically update the version resource file (whether from AssemblyInfo.cpp or through a separate version incrementer).
maybe this can help you with your problem :
http://www.codeproject.com/Articles/37133/Simple-Version-Resource-Tool-for-Windows
Michael