When such project is exist in solution file, monodevelop writes: "The project type is not supported by MonoDevelop"
Which project types (by their guids) are not supported in which versions?
The lists of project types (which are supported by different versions of MSVS) are probably provided in MSDN (but how to find their guids?)
http://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
MonoDevelop has a built-in list of all project types that are either not supported or require an optional addin.
You can find that list in the source tree in the file MonoDevelop.Core.addin.xml.
Under <Extension path = "/MonoDevelop/ProjectModel/UnknownMSBuildProjectTypes"> element you'll find the project types you're looking for. As an example:
<ProjectType guid = "{42C0BBD9-55CE-4FC1-8D90-A7348ABAFB23}" name = "Xamarin.Mac" platforms="mac" product = "Xamarin.Mac" />
At the time of posting you'll find the real thing here but that might change.
Related
I am confused here. I have migrated my CHM help from HtmlHelp Workshop to HelpNDoc. I compiled the CHM file and updated my MFC project to direct to the correct topic:
HtmlHelp((DWORD_PTR)_T("msa-options-publishers-db.html"), HH_DISPLAY_TOPIC);
The above approach worked with my previous CHM file. When I invoke this call the following happens:
It doesn't find it. Now I am having difficulties here because if I click F1 in my IDE (VS2017) it takes me to here. This article provides an example for showing a topic:
HWND hwnd =
HtmlHelp(
GetDesktopWindow(),
"c:\\Help.chm::/Intro.htm>Mainwin",
HH_DISPLAY_TOPIC,
NULL) ;
The above HtmlHelp API call is taking 4 parameters. Yet, in my CDialogEx derived class I only have two parameters:
So I need to find a way that will work to open any topic in my CHM file as compiled with HelpNDoc.
Update
On further research I located the topic that discusses the HtmlHelp API call that I am using (found in the CWinApp class). It states:
Parameters
dwData Specifies additional data. The value used depends on the value
of the nCmd parameter.
nCmd Specifies the type of help requested. For a list of possible
values and how they affect the dwData parameter, see the uCommand
parameter described in About the HTMLHelp API Function in the Windows
SDK.
So we end up here where we are given a link to details about HH_DISPLAY_TOPIC. We have gone full circle. Looking closely it states:
Specifies a compiled help (.chm) file, or a specific topic within a compiled help file.
To specify a defined window type, insert a greater-than (>) character followed by the name of the window type.
So my code should still be fine.
You won't believe how simple the resolution to this issue was!
I did a test with HTML Help Workship API window:
The only one that worked was when I used htm as the suffix and not html. See:
Premise
I have a Visual Studio 2015 solution containing different VC++ projects.
Some of them (EXE and some DLLs) have the $OutDir set to default "$(SolutionDir)$(Configuration)\" (i.e. "C:\MySolution\Debug\").
For some other projects (DLLs), I need to change the output path to a sub-directory of the "default" $OutDir (i.e. "C:\MySolution\Debug\Pieces\".
Example directory tree:
C:\MySolution\Debug\
MyProgram.exe
Dependency.dll
.\Pieces\
MyPiece1.dll
MyPiece2.dll
Constraints
the "Pieces" DLLs depends on a third-party Dependency.dll (through NuGet package), which I cannot modify.
Usual solution
The usual way for this is to change the $OutDir project setting for "pieces" projects, but this will also force their dependencies to be output in the same sub-dir.
This is not wanted and also created problems in debugging and packaging of the entire solution.
What I tried so far
I tried to:
1. keep the $OutDir the same for all projects
2. change the "pieces" $TargetName to "Pieces\$(ProjectName)"
This seems to work (both MyPiece*.dlland Dependency.dll are correctly placed and debugging is fine), but unfortunately Visual Studio generates the following warning:
warning MSB8012: TargetName(Pieces\MyPiece1.dll) does not match the Linker's OutputFile property value (MyPiece1). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).
This warning is somewhat confusing, because the %Link.OutputFile in the project settings looks correct:
$(OutDir)$(TargetName)$(TargetExt) => C:\MySolution\Debug\Pieces\MyPiece1.dll
Question
What is the correct approach to solve my problem?
How do I force Visual Studio to output some of the generated files in a different path, but still having their Nuget dependencies in the "default" $OutDir?
I've searched the web and StackOverflow already, but I can't find a suitable answer.
Note: my problem is not related to upgrading a pre-VS2010 solution (as in Microsoft official notes on warning MSB8012 after solution upgrade and asked on StackOverflow).
I am working on a project that involves the use of JSON to store and retrieve data; in order to write some example data I am using VS2013's JSON editor, which supports, supposedly, the use of arbitrary JSON schema for its Intellisense code-completion feature. However, I have not been able to get it to recognise any schemata that are not accessed through a website, e.g. http://json-schema.org/draft-04/schema works fine but /JSON/mySchema.json does not.
It will not load /JSON/mySchema.json from the $schema tag, nor will it allow me to type in its name; whenever I type it into the schema box and hit enter, it returns the schema box to "No Schema Selected".
How do I get VS2013 to recognise my custom schema and generate Intellisense completion from it?
I've learned (from comments on the announcement page for this functionality) that using relative paths for JSON schema is currently bugged in Visual Studio 2013 Update 3;
"[...] the relative $schema path is not working in a non-web project and will be fixed in Update 4."
(from a comment on this page)
It should work fine with an absolute path, but of course that's not portable. Update 4 should be out soon; the RC is already out, and information can be found here.
Is there a tool / process by which I can decompile two .exes (one of which runs on a handheld device, the other which doesn't) so that I can get a glimpse into what differs/what the problem may be?
Of course, seeing that one has "00xA" where the other has "00xB" won't help me. I mean a way to see code that differs, or more likely, a compiled resource or config file difference, or some build option or so?
I'm almost positive the problem has nothing to do with code per se (if/while/switch statements, etc.) but with the project setup.
I cannot compare the working source, as it does not exist - I only have the .exe from which it came. The source I have available is a "reasonable facsimile" of it, but not exactly the same, at least not in project settings and configurations, etc.
UPDATE
Re: this page, I'm not familiar with some of the terminology; specifically, where it talks about a "FLATRELEASEDIR" - WTH?
Will this work to test my CE-bound* .exe on my PC:
Run depends.exe*
Open my CE-bound** .exe
Stare in wonder at the amazing plethora of errata and data
?
*Supposedly not to be confused with "adult diapers"
** "bound" as in, "that's where it's headed"
UPDATE 2
Here's what I see when running Dependency Walker on my app:
...but note my dilemma here.
UPDATE 3
Here's what I did to try to replicate my handheld environment on my PC as best as possible:
I wanted to just copy over the whole dad-burned thing (the entire handheld device representation from Windows Explorer), but it won't let me do that - it's not copyable, so I copied over just the "Program Files" folder (which contains the subfolder of my app and a couple of other folders which I don't know are standard or custom/peculiar to us).
This is from the handheld device where the .exe in question does run properly, so obviously (theoretically?) there should be no missing modules - Dependency Walker should run it and say all is well.
However, it doesn't; I get the same results as the one p[a,o]sted above.
Note: This is true even after selecting "Options > Configure Module Search Order... > The Application Directory > Move Up in Dependency Walker.
So since even an .exe that runs fine tests out as being "not ready for CE-time", how can I use this to accurately test which, if any, necessary files are missing?
Do I need to copy over other folders, too, or what?
UPDATE 4
So, the (supposedly?) missing modules are:
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
If true, then why does the .exe run on the handheld?
Note: Other folders on the handheld are:
Application Data => only contains "desktop.ini"
BTExplorer
My Documents => contains a "desktop.ini" and several SQLCE databases (*.SDF)
profiles => contains an empty "default" folder
Recycled => contains a single ".lnk" file
Temp => contains a handful of ".tmp" files
Windows => contains a slew of folders and files, including several .DLLs, but none of those listed above
The "Program Files" folder has a ".NET Compact Framework" subfolder, but it is empty.
In the \Windows\AppMgr folder, there are some interesting files, such as:
Microsoft .NET Compact Framework.DAT
Microsoft .NET Compact Framework.DLL
...several other DAT/DLL pairs, including:
Symbol Managed Class Libraries.DAT (no corresponding DLL)
...and even a pair:
SSCS HHS.[DAT,DLL]
-- which is our company acronym (SSCS) and name of the project (HHS)
What generates these? From where are they referenced??
Another possible piece of the puzzle is that the handheld device on which the .exe does not work does not have a \Windows\AppMgr folder, and thus does not have those .DAT/.DLL files listed above...
UPDATE 5
Another oddity:
After reading this: "Files that install in the GAC go in the\Windows directory" in the book "Microsoft .NET Compact Framework" by Andy Wiggly, et al, I tried copying the Windows folder from the handheld device to the spot on my PC below the folder named "3910ProgramFilesFolderCopy" which looks like this in Explorer:
C:
3910ProgramFilesFolderCopy
Program Files
Windows <= tried to copy the "Windows" folder from the handeld on top of "3910ProgramFilesFolderCopy" so it would end up here
...but it only copies a few files before borborygmas occurs (electronic borborygmas, that is) and it tells me, "the system cannot find the file specified"
Heavens to Murgratroid!?! Why does it find some but not all? Looking at the Windows folder on the handheld in Windows Explorer, I see that many of the precious DLLs are greyed out:
Arggh, double-arg, and (&c)
For PC you could try .NET Reflector.
http://www.red-gate.com/products/dotnet-development/reflector/
You may try to use dependency walker to undestand wich DLL/APIs they need and check if those are supported on your device.
http://geekswithblogs.net/WindowsEmbeddedCookbook/archive/2011/02/02/using-dependency-walker.aspx
The question is how to resolve conflicts between versions of assemblies in my project that was upgraded to MVC4 and EF5?
The problem is manifest in the fact that my controllers and models can include System.Data.Objects, but now my views.
I am using MVC 4, my project was upgraded from MVC 3.
Entity Framework is version 5.
I have a controller that is able to use objectcontext from System.Data.Objects.
My Usings:
using System.Data.Objects;
using System.Data.Entity;
When I try to include the using in the view form System.Data.Objects, I get :
CS0234: The type or namespace name 'Objects' does not exist in the namespace 'System.Data' (are you missing an assembly reference?)
I am targeting .net 4.5
My Build Displays this message:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1561,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
You can build your solution in diagnostic mode to get more detailed information about the error.
Open the VS Options dialog (Tools > Options), navigate to the "Projects and Solutions" node and select "Build and Run". Change the MS Build project build output verbosity to Diagnostic.
Have a look here.
If you look at the build message, it states the 4.0 version of the .net framework is referenced... Is there a setting in your project file or web/app.config specifying a conflicting version of the .net framework?
Are you familiar with fuslog? you can set it up to log all assembly bindings that .net is doing while running your application. You should then be able to see detailed information on what is getting bound when. If you still can't figure it out, you can always do a binding redirect on that .dll in the web.config.
http://msdn.microsoft.com/en-us/library/eftw1fys.aspx -- binding redirects
http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx -- fusion log viewer
Set up fusion logger and take a look at what the output is. If you don't get an answer from that, try the binding redirect (which would give you at least a temporary solution).
In the directory I was publishing to, there was a folder named aspnet_client. I moved it (instead of deleting it), republished, and it worked. I'm not sure why that folder decided to give me trouble out of the blue.