Say I have a SqlClr project called MySqlClrProject, which builds the file MySqlClrProject.dll. I've observed that the Build output file name can be either MySqlClrProject or MySqlClrProject.dll, but either way will produce a file named MySqlClrProject.dll. I also have another project in my solution, called MyClassLibrary, which has a project reference to MySqlClrProject. When I build MyClassLibrary, I'll see this error:
CS0006: Metadata file 'C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject' could not be found
Before that, in the output, I see this:
ResolveAssemblyReferences:
5> Primary reference "MySqlClrProject".
5> Could not find dependent files. Expected file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject" does not exist.
5> Could not find dependent files. Expected file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject" does not exist.
5> Resolved file path is "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject".
5> Reference found at search path location "".
5> Found related file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject.pdb".
5> Found related file "C:\devStuff\MySqlClrProject\bin\Debug\MySqlClrProject.xml".
5> The ImageRuntimeVersion for this reference is "".
If I add a post build step that copies MySqlClrProject.dll to MySqlClrProject, all is well. Alternatively, if I reference the dll directly, as opposed to using a project reference, then, again, it works fine. I'd really rather not go either of those routes...
Anyway, has anyone else seen this? Anything I might be doing wrong? I know VS2012 is very new, and they've changed a lot when it comes to SqlClr projects, but I'm wondering if the problem is on my side or Microsoft's.
Thanks.
Related
Using Eclipse 2020 with 2 different Projects. Each Project has their own Workspace.
Workspace1/Project1 Run as expected.
Workspace2/Project2 generates the following error indicating an inability to find MyJarFile.jar:
All the Build values are the same, but when comparing the Dependencies between the working and failing environment I noticed the following.
The working environment shows reference to MyJarFile.jar as an actual path reference.
The failing environment shows reference to MyJarFile.jar as a reference via the Project Name.
The strange thing is when I first Add MyJarFile.jar it shows the actual path name, but after closing and reopening the Dependencies tab, it converts the \MyProject\ reference.
In both scenarios it has been confirmed the file exists.
Also, the addition of the File was done using the dialogbox so that also confirms it exists.
Questions:
1 - Is there a setting which dictates when the actual directory reference is shown and when the \Project\ reference is used?
2 - When the \Project\ reference is used, is there an extra step required so the associated file is actually found?
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
I have downloaded a project from a repository that refers to another project. I'd really like to build this project with Codewarrior 10.4's command line tools. However, the reference path in my .project file doesn't correspond to the location of the project it references, on my computer. I needed a command-line, programmatic way of changing the reference path to the correct location on my machine. So I tried
ecd -references -project project_pathName -allConfigs -remove wrongReferencePathName
with the intent of then running
ecd -references -project project_pathName -allConfigs -add correctReferencePathName
But the first command gave me a file not found error. So, it looks like I can only remove references to projects that actually exist on my system, and can't get rid of bogus references to projects that aren't even valid locations on my filesystem.
Is there any way to remove a bad reference, one that doesn't correspond to a valid project location, from the command line? If not, can you think of any other way I might approach this issue?
Just for context, the way our company avoids this issue normally is via representing our projects and their references in a .wsd file. We drag-drop the file into the CodeWarrior GUI, and this automatically fixes all the references in all our .project files. The issue is that we can't figure out how to invoke the wsd file from the command line. If you know of any way of doing this, it would actually be much more helpful than an answer to my other question!
I tried multiple options for wrongReferencePathName. Above I tested "file:/C:/Development/DSM33/DSM33_India/DSM33_FS_v02.02/AlphaBoot", but I also tried "C:/Development/DSM33/DSM33_India/DSM33_FS_v02.02/AlphaBoot" and "C:\Users\Ross\Desktop\Round2\DM3\Freescale\DSM33_FS_v02.02\Firmware.project".
They all produced the same error. The paths I'm trying don't exist in my filesystem--I have different paths to the referenced projects in my filesystem--so it kinda makes sense that I'm getting a fileNotFoundException. Maybe it's that the references tool is looking for a .project or .cproject file at the provided reference path and crashes out if none is found.
If this is true, I might try spoofing the bogus filepath in my system and copying over a .project file, but this is a real pain.
It's also possible that I'm just not using the referencedProjectLocation argument correctly--for reference command syntax is
ecd -references -project path [-config name | -allConfigs] ( -list | -add | -remove) referencedProjectLocation [buildConfigurationName]. I'm assuming this argument can only take a project filepath, but if I'm wrong or if there's a different way to identify a project with this argument, I'd love to know!
Here is the error output--not sure the full backtrace will be helpful
Thank you so much on your help for this one!
-Ross
After a clean Windows reformat and installing Visual Studio 2013, trying to build a project with database-first Entity Framework edmx files yields the following error:
The "EntityDeploySplit" task could not be loaded from the assembly
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll. Could
not load file or assembly 'file:///C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Data.Entity.Build.Tasks.dll' or one
of its dependencies. The system cannot find the file specified.
Confirm that the declaration is correct, that the assembly
and all its dependencies are available, and that the task contains a
public class that implements Microsoft.Build.Framework.ITask.
Is there some way to install this separately? What is this assembly included with by default?
UPDATE: This also manifests itself when looking for the EntityClean task. I'm inclined to think that it checks the bin first, since another developer who was running it fine tried a clean / rebuild and then this started showing up.
I found the accepted answer to be a little confusing, below are the steps that worked for me.
Open C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets in notepad.
Alter the UsingTask elements to:
<UsingTask TaskName="EntityDeploySplit"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploy"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityDeploySetLogicalNames"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
<UsingTask TaskName="EntityClean"
AssemblyFile="Microsoft.Data.Entity.Build.Tasks.dll" />
I ran into this problem and was able to fix it as I have described below. Your paths and variables may be different.
I found that when my project builds it points to this target file:
C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Data.Entity.targets
That target file appears to just be a placeholder. There is an Import element, in that file, that points to $(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.targets which runs the target file located at that path. I searched registry and found that MSBuildFrameworkToolsPath is a registry entry with the value of C:\Windows\Microsoft.NET\Framework\v4.0.30319\
I went to the targets file that was referenced and search for the UsingTask element that was specified in my exception. Inside the UsingTask element, the AssemblyFile attribute was pointed to $(MSBuildBinPath)\Microsoft.Data.Entity.Build.Tasks.dll. I searched the registry and found that the MSBuildBinPath registry entry was pointed to c:\Windows\Microsoft.NET\Framework\v3.5\
I'm not sure why it was pointed to that, maybe a Framework or Visual Studio installation didn't clean it up. Finally, I changed all my UsingTask elements' AssemblyFile attributes to:
$(MSBuildFrameworkToolsPath)\Microsoft.Data.Entity.Build.Tasks.dll
I used the same variable that was in the MSBuild Bin target file.
Hope this helps.
I give a lot of credit to Andy Mahaffey for his answer, without it I would not have found what I did.
I followed along his line of research but didn't like the idea of just changing the UsingTasks' attributes. I opened up the "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Data.Entity.targets" file and I found the first thing it says after the opening Project element is this comment:
<!-- This .targets file can be used by updating Microsoft.Common.targets to
include the line below (as the last import element just before the end project tag)
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
-->
I followed it's suggestion and presto, problems solved.
I hope this helps!
TLDR
Paste the line below as the last element before the tag in the following file. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
<Import Project="$(MSBuildBinPath)\Microsoft.Data.Entity.targets" Condition="Exists('$(MSBuildBinPath)\Microsoft.Data.Entity.targets')"/>
In my case, I had accidentally created two copies of one of my .edmx files, one in a subfolder, where I didn't notice it. Once I deleted the extra one, everything was fine.
This seems so trivial, yet I can't get it to work..
I have an msi.dll wrapper (named Interop.WindowsInstaller.dll) which I need to sign. The way to do it is by signing it upon import (this specific case is even documented in MSDN: http://msdn.microsoft.com/en-us/library/zec56a0w.aspx).
BUT - no matter how I do it (w/ or w/o a keyfile, w/ or w/o adding "/delaysign"), the generated assemly's size is always 36,864 bytes and when viewing the DLL's properties there is no "Digital Signatures" tab (needless to say - the DLL is NOT signed).
What am I missing here?? (... HELP!...)
[Note: Eventually I got a hint from Karel Zikmund on this thread, which helped me solve the mystery. I'll paste my reply here - for the greater good].
So, I used the following line to sign-upon-import the assembly:
tlbimp C:\WINDOWS\system32\msi.dll /out:Interop.WindowsInstaller.dll /keyfile:MyKey.snk
I then copied the file to the appropriate location and built the project, but each time the build failed on the following error: Assembly generation failed -- Referenced assembly 'Interop.WindowsInstaller' does not have a strong name.
I thought the problem was with the tlbimp line, but after reading Karel Zikmund's reply and verifying that the DLL is strong-named (using sn -vf Interop.WindowsInstaller) I found out the problem.
Adding a reference to the "Microsoft Windows Installer Object Library" COM object actually planted a code block into the .csproj file.
I didn't realize it, but this block caused the DLL file to be regenerated from scratch upon each time the project was built. The generated file, of course, was not strong-named anymore.
The way I resolved it was to remove the reference to "Microsoft Windows Installer Object Library" from the project, and add a direct file reference to the imported (and already signed) Interop.WindowsInstaller.dll file.