I try to load a F# project with Visual basic 2011 beta and I have the following issue, which appears for the first time :
There is a missing project subtype.
Subtype: '{5B89FCC2-C9F6-49a8-8F8D-EDDCC3FDC9E9}' is unsupported by this installation
Do you know how I can solve this problem?
At some point (VS2010?) you installed the FsProjectExtender to get some extra functionality available to F# projects in Visual Studio. Just re-install that extension again for VS2011 and you should be OK, or remove the dependency in the .fsproj file as noted by #Brian.
I don't know what that guid is for (Bing search did not turn up much), so you might simply try removing it from the ProjectTypeGuids in the .fsproj file (leaving only f2a71f9b-5d33-465a-a702-920d77279786 which is for the F# project system).
Related
I have a project that uses the NuGet package System.Data.SQLite for accessing the DB.
At compile time all works fine, but at runtime when I initialize the connection this error occurs:
System.DllNotFoundException: SQLite.Interop.dll
I have tried to install the NuGet package System.Data.SQLite.Core but nothing changed.
How can I solve this? Anyone has found this error too?
Thank you!
I have checked the tags and the dependency of the package, it seems the package doesn't support Xamarin. In addition, there were two existed case which had the same problem. You can check this two case.
Both of them used the Microsoft.Data.SQLite instead of the System.Data.SQLite. So you can also choose to use this package.
I'm trying to build the minimal wxWidgets sample on Windows, using Visual Studio 2019 Commmunity Edition, following the instructions from this page for using wxwidget binaries
I opened the "minimal_vc9.vcxproj" file in Visual Studio. Visual Studio upgrades the project file.
I then added the wxwidgets.props property file to the property manager, and then tried to build ( Build | Build Solution )
It fails with the following error:
1>C:\Users\Administrator\Desktop\wxwidgets\include\wx\msw\chkconf.h(91,1):
fatal error C1189: #error: "wxUSE_UNICODE_MSLU must be defined."
I am trying to help a friend who knows C++ and uses Windows to set this up, but am not sure how to do so. Note both he and I are new to using Visual Studio as well, and I can't find any references on how to fix this by Googling.
Note I am using the project file that came with minimal (no solution file was there), and can see that in it's configuration that it says "Use Unicode Character Set" at `Project | Properties | Character Set"
EDIT: I'm attaching a picture of the IDE/files we downloaded, which I believe are the 3.1.5 version, ie release version as of Dec 4, 2021?
It looks like you're using wxWidgets 3.0, as support for MSLU was removed since v3.1.0 ~8 years ago. Please download 3.1.5 binaries and open minimal.vcxproj project file to build the sample, there is really no reason to use a 10 year old version if you're starting developing with wx.
Also, completely unrelated, but it's considered to be a bad idea to use administrator account for development. wxWidgets certainly doesn't require any special rights.
I
It is very easy to build the library yourself.
Download the source code archive and unpack it in, e.g. c:\wxWidgets
Start msvc, do ^File->Open", navigate to c:\wxWidgets\build\msw and open the file wx_vc15.sln
Select "Build->Batch Build...", click "Select All", then "Build".
When the build is finished successfully, open c:\wxWidgets\samples\minimal\minimal_vc9.sln, let msvc convert it and choose " Build->Build Solution".
Then when everything is ready, create a project as "desktop application", apply the properties file and start coding.
Thank you.
I am developing a C# project in Visual Studio 2019. I've read that it should produce .csproj.user files automatically, but it is not. How do I force Visual Studio to produce a .csproj.user file? Thank you.
As mentioned by Hans Passant above, this file is created when there exist user-specific settings. Typically it is created by changing any of the Project->Properties->Debug settings to non-default values (i.e. specifying command line arguments or setting an absolute path for the working directory).
However, as I already have pointed out in the other question, I believe you should not commit this file and find out why you have problems without it. Or rather, why VS adds some relevant information to this file instead of the main csproj.
In my case strangely some references that should have been in the SDK project had found their way into the csproj.user file. I don't know why this happened.
Once I put the references back in the SDK project I had no need for the csproj.user after all.
We just set up TFS 11 for the first time. Running a gated check in, it succeeds but returns this message:
'srctool.exe' returned an unexpected exit code: '-1'. An error
occurred when opening a file "CustomDllName.dll": Assembly
"CustomDllName.dll" is not a valid .NET assembly and will be skipped
for analysis.
Well, it's right: that file is a legacy Visual Basic 6 DLL that we don't have much control over. It's included in the project for COM access to some of the methods.
Is there a way to instruct srctool.exe/TFS to skip that file when doing the inspection? Or another way to attack this?
Here is the solution that ultimately worked for me
A member of the TFS 11 team at Microsoft mentioned to me that the problem is due to a change in behavior that the Windows 8 team made to the srctool.exe tool.
By copying this file from the Windows 7 SDK (WinDBG) toolkit and overriding the one included in TFS 11 Beta, I was able to successfully run a build without any errors.
Is this a srctool.exe error from the shipped IndexSources activity? srctool.exe in this activity does one thing, which is to list the source files information in the pdb. I am not a srctool expert so I don't know why it fails in this case. I do know that srctool.exe has some behavioral changes in version 11, most of those are fixes from the previous version.
There is a workaround which requires udpating the build template. It is not very nice but it works. Srctool.exe is run (inside IndexSources activity) for each pdb file in the SymbolFiles collection. Now that you know which pdb fails, you can update the build template to add a RemoveFromCollection activity before the IndexSources activity that remove the troubled pdb from the SymbolFiles collection. This is by far the most straightforward workaround I can think of.
Alternatively, you can edit FindMatchingFiles activity's search pattern to exclude the pdb files you don't want to have sources indexed.
Based on the error message you got, it doesn't seem to be related to the known issue Ed mentioned. We fixed this issue for the next release, so if it's related, it should be fixed :-)
Let me know if you have any issue with VS11 Beta around the build templates.
Thanks.
i have created a windows service in visual studio c#.net ,and i am trying to create a set up and deployment for the service, when i am buiding the windows service project ,it is successful
i have added the Project Output Group as Primary Output with windows service project.
i have also added the custom action to the set up project,
when i try to build the set up project it displays"An error occurred while validating. HRESULT = '80004005'" i also noted there is nothing in the detected dependencies folder.
I had the error code 8000000A, so it might be different, and I'm not sure if this is any help for your problem. But re-adding references did not work for me. However, what worked for me was removing the .suo file (next to the .sln) and (re)building again.
(It might have been caused by accidentally opening a Visual Studio 2010 class library in a Visual Studio 2008 comapct project. I am not even going to try reproducing this!)
Removing the .suo will make you 'loose' your open files (and maybe some other settings?), but IMHO that's just a small sacrifice(?).
I just hope this will save someone some time...
I've just had exactly the same issue with a WinForms project. I had several projects in my solution, they would all build without an issue except for the set up project.
I overcame this by removing all the references to the other projects in the solution in the main project (the one that was being set as primary output) and then re-adding them again by going to add reference >> project. Once I had re-added the references to the other projects in the solution, the project dependencies re-appeared and all built fine.
Hope that helps
Richard