I wonder if this is some sort of reference issue in Visual Studio Express 2013. I am building from source so none of these files should have to be registered after the fact. Upon running the type library from the bin folder in an external program as a custom command, it returns the interop.scripting.dll not found error. What could be causing this? Does it matter that some reference paths for COM files point to the obj folder and not bin (I think this is normal)?
Example references (I can't post images yet) --
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.esriSystemUtility.dll
C:\Program Files\ArcGIS\DotNet\ESRI.ArcGIS.Catalog.dll
C:\FNNTQuarterlyReports\SourceCode\obj\Debug\Interop.Scripting.dll
c:\Program Files\Microsoft Visual Basic 2005 Power Packs\3.0\Microsoft.VisualBasic.PowerPacks.dll
This has been solved. Not entirely sure of the details, but I started fresh with a backup copy of the source and left the original .NET and COM references as-is. The key difference is the use of powerpacks.VS as opposed to the new 3.0, and older ESRI dlls (dating to 9.1 period). All had copy-local set to true. For some reason this build works fine... trying to modernize the references somehow messed things up, possibly due to a compatibility issue, or some other oversight. Thanks for the help.
Related
The 'template' for the new project is MFC Dynamic Link Library. The problem seems to boil down to Visual Studio looking for the folder "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v142" - which doesn't exist. I have run and re-run the Visual Studio installer - always adding more things for toolset v142, but nothing seems to help. Is there some way to get this folder to appear? With the right stuff in it?
In reality, I am upgrading an existing project from umpteen versions back to be compiled with VS 2019. Because I could not get it to compile, I tried to create a new project to stuff with the files from my old project and the problem occurred before I even added any files to it.
I have done a similar process to compile my project for previous versions of VS, but never had this problem before. Any help appreciated.
To prove your issue, I have made a small test:
1) create a new system environment variable called VCTargetsPath and then set its value to
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\
2) then restart VS and also set the the Platfrom Toolset to v142under Project Properties.
3) then rebuild the project and get the same error:
Since you new created project has also the error, so I think you have do some changes to system environment variable.
Also, you should note that this path is for old VS2015.
However, VS2019 uses:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Platforms\Win32\PlatformToolsets\v142
You make a change so that it will overwrite the system value for VS2019 which leads to the issue. The value is global and affects all the vs versions on your current PC.
Suggestion
1) You should check your system environment variable and search for VCTargetsPath, if you has this variable, please delete it.
2) or if you have this variable VCTargetsPath, change its value to, or if you do not have it, create it and set its value to VS2019.
I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]
I have the following warning when building some of my class library csprojs:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2110,5): warning MSB3101: Could not write state file "..\..\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug
\anvil.controls.vs2017.net461.csprojAssemblyReference.cache". The file 'E:\anvil\Anvil.Controls\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug\Anvil.Controls.vs2017.net461.csprojAssemblyReference.cache' already exists. [E:\anvil\Anvil.Controls\src\anvil.controls\anvil.controls.vs2017.net461.csproj]
I've tried using msbuild 15.0 (VS2017 and Standalone 2.2.103) and 16.0.
Same warning in Visual Studio 2017 and JetBrains.Rider
Does not happen if I wipe my temp folder. Then happens in subsequent builds or even rebuilds.
Happens to a subset of my projects, only similarity I can see is that they are all projects that contain .xaml files. But it doesn't happen on all projects with .xaml files.
Happens when I use -maxcpucount:1 (to disable parallel build).
Each project has a unique tmp/intermediate folder, set to this: ..\..\tmp\dotnet\ubisoft.controls\<bin|obj>\vs2017\net45\<debug|release>\
Any ideas what might affect this error in my projects?
Sometimes 'mysterious warnings' (and errors) come from too long paths. Try to use a shorter output path, i.e.
E:\build\Anvil.Controls\tmp\net461\debug\
instead of
E:\anvil\Anvil.Controls\tmp\dotnet\anvil.controls\obj\vs2017\net461\debug\
See this answer as well
I'm struggling to get a simple COM Server running in Visual D 2010. These are the steps I did so far:
Clean Visual D 2010 solution of type Dynamic Library (DLL)
I've copied contents of dserver.d into dllmain.d
I've copied file chello.d and dserver.def into the solution's source folder, as well as advapi32.lib and ole32.lib from the <D install dir>\dmd2\windows\lib.
I've added the copied file into the solution by right-clicking the project in the solution explorer and Add->Existing item...
Renamed file dserver.def into dll.def, overwriting existing project's file.
Applied a patch to the chello.d and dllmain.d (originally dserver.d) as written on this forum thread
Build Debug. No errors.
Calling regsvr32 COMServer.dll returns these four message boxes:
then
then
and finally
I am still unable to access the COM object from VBA. And referencing the DLL directly (by Browse... button and pointing to the COMServer.dll) fails with "Can't add a reference to the specified file."
I took another look at the forums and the problem with the samples seems related to TLS on Windows XP. I posted a (somewhat hacky) solution to it here:
http://forum.dlang.org/thread/mqoxluonyjdtjxauaxnl#forum.dlang.org?page=2
I can't provide you with a working answer. It looks like this was a year ago, I was trying to get an example of using a COM server working. This uses Juno (not 64bit ready), has nothing to do with Visual D, and most importantly I couldn't get to work. The issue I hit was related to registering the server ("side-by-side configuration is incorrect").
My qualifications for COM are all there in the history of Juno (so not much of any). If you're more familiar with COM you may get further, if it doesn't compile for the latest DMD let me know (2.064 isn't out yet anyway).
WSPBuilder
Version: 0.9.8.0830
Created by Carsten Keutmann
GPL License 2007
Install and deploying [MYDLL]
Unable to deploy solution
Inner exception(1): This solution contains one or more assemblies targeted for the global assembly cache. You should use a strong name for any assembly that will be in the global assembly cache.
I had the same issues but what worked for me was to delete all the files in the bin and obj folder and then rebuild the WSP.
In my case, I was getting some strange errors (can't remember the exact message) when using Delay sign only option for one project.
I have found the problem, but not the solution, it seems the project I have which is really a 12 hive, is also set to output a class library, this class library is getting included in the WSP.
So... I need to ensure the bin folder is really excluded from the build process.
I set the value in program files but no reaction yet...
Now going to restart the server...
Later: Ok - the fix is to restart the server, for some reason this helped
I'm experiencing the same issue, one solution, multiple projects, the one failing to compile is using an object from another project.
I've tried clearing the bin & obj folder, as well as restarting the server. I think I'll copy the files dll to the gac using gacutil instead.