I've been using a solution which contains three projects for a long time. Something has changed, and now VS is hanging when trying to open one of the projects in Solution Explorer. The three projects consist of a Fortran dll project, a C dll project, and a CPP mfc executable project.
I can build successfully, and can view the Fortran and CPP files in solution explorer. However, when I try to open the C project in explorer, VS hangs.
I created a new solution and re-created the C dll project in that solution, by adding the C source code files. It worked fine when using solution explorer to view the source code.
Then I replaced the C dll project in the original solution with the new C dll project. However, VS still hangs when I try to view the files in the C dll project.
I then replaced the C dll project in the new solution. Now VS hangs when trying to open the C dll project in the new solution.
Mike
I fixed the problem by removing the ClearCase integration from VS. I am moving to a free version control system shortly anyway, so this won't be a major problem.
Mike
Related
I'm learning F# and I'm just trying to build Animate a pendulum program.
Here's the code:
https://rosettacode.org/wiki/Animate_a_pendulum#F.23
As far as I understand, VS 2019 doesn't support WinForms in F# (maybe, I'm wrong), so I have error messages, trying to copy/paste that code:
What should I do?
Thanks a lot !
If you're looking to use Winforms on .NET core, you'll need to do the following in your project:
Open the project file (double-click on the node in Visual Studio)
Change the Sdk to Microsoft.NET.Sdk.WindowsDesktop
Ensure you have this OutputType: <OutputType>WinExe</OutputType>
Add the following property to the top-level PropertyGroup: <UseWindowsForms>true</UseWindowsForms>
There won't be a visual designer to use, but you should have access to the APIs.
Unfortunately, there is no Winforms designer in Visual Studio 2019 for F# projects of any type, and Winforms can only be easily accessed (as far as I know) in .Net Framework (NOT .NET Core) projects they can be accessed as per #Phillip Carter's answer.
However you can still make Winforms programs easily by manually adding the references to your .NET Framework project, or (more easily) by manually compiling with the F# compiler, fsc.
The Fast Way
The easiest way to do this is simply compile the source code with the F# compiler from a single source file with fsc.exe. The F# compiler will automatically resolve dependencies for things like System.Windows.Forms and a lot of other commonly used namespaces. You can also provide lots of compiler directives for requiring other resources as well.
Example using VSCode, with various extensions:
Another Way
Start a new F# console .NET Framework project (don't pick .NET Core).
Right click on "References" in the Solution Explorer and click "Add Reference..."
Under assemblies, look for "System.Windows.Forms," select it...
And also select "System.Drawing" and then hit OK
Now you have access to both of those namespaces.
Before you run the project in Visual Studio, you should replace
[<STAThread>]
Application.Run( new PendulumForm( Visible=true ) )
with
[<STAThread;EntryPoint>]
let main _ =
Application.Run( new PendulumForm( Visible=true ) )
0
This way you (and VS) know where main actually is. It's not necessary for this small of a program to actually run it, but as your projects get larger VS will complain more about where things are located in your project.
I have 2 c++ projects in different solutions. When I built the project B solution's it generated a .dll, .exp, .exe, and .lib files.
How I have to reference the project B in the project A?. I've tried rigth click -> add -> reference -> B.dll.
But it shows me a window error with the following message:
could not add a reference to B.dll for one of the following reasons:
Targets a higher version of the .NET Framework
Not a .NET assembly
Not a registered ActiveX control
I've never worked with visual studio,I'm a little bit lost
Thank you and sorry for my english
I am trying to build a project from the following Source Code (it accompanies a book I am currently reading). Unfortunately, visual studio can not run a library with the name "cyclone_d.lib". I believe this is because visual studio simply can not locate the file. I have spent several hours trying to fix this problem by changing the settings in the linker and project, for example adding Additional Directories, but I have not been able to get any results.
Please let me know how I can fix this problem and compile the code.
Thank You!
Your link to source points only to some Unix-style source files but no VS project files. So I can only guess and give general help.
A VS solution contains one or more projects. Each project has a build target, in most cases a EXE, DLL, or static library LIB. When you have a solution that includes an project with an EXE build target set the option "Set as StartUp Project" at that project in the solution tree.
If you don't have an EXE change your project setup to create a Win32 executable instead a library. For this task the most simple approach is creating a new project (Win32 Console Application or Win32 Project) and add all the source files.
I have 3 C# projects, A (WPF application), B (class library), and C (class library), such that A references B, and B reference C. Project C needs to call some native methods from a C++ DLL via P/Invoke. I added the native DLLs to the C# project and marked them a "Copy to Output Directory". When I build my solution, the native DLLs show up in the output directory for Projects B and C (correctly), but not for Project A. Is there a project setting that allows these to be copied by any project that ultimately references Project C (even if not directly)? Or do I just need to post-build event on Project A to copy this files to my application output folder?
I've looked at Dependencies of references not copied to output directory, but this was referring to project references, so I'm wondering if there is a solution in my case.
I also considered embedding the native DLLs as resources and modifying my DLLImport as in this MSDN article: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx. But I get an E_ACCESSDENIED error (I've seen others with this same issue as well, as well as some concerns about triggering antivirus behavior when extracting the DLL to disk). I also noticed the article mentions linking the resource, rather than embedding it. Is this something I need to do as an MSBuild task, rather than through some project properties?
Worst case, I could just add a post-build event to my WPF application that copies the native files, but it would be nice if Visual Studio would recognize that these files should be copied.
I solved this by customizing the output for debug/release mode compiles (on the project properties window) so that all of my projects outputted to the same folder... Much like how an ASP.NET application is published where all DLLs end up in a single /bin folder. That fixed my issue.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.