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).
Related
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 3 C# projects A, B, and C. Both A and B reference C. The references to C from A and B are set to "Copy Local" implying that after C is built to C.dll (in the output directory of C), it is copied to the output directory of A or B (whichever is being compiled)
I have 2 solutions, SA and SB. SA contains A and C and SB contains B and C. I launch 2 instance's of Visual Studio 2015. I open SA in one instance and SB in the other.
I am finding that if I Start Debugging (F5) A from SA, and then (while A is still debugging), make a change to C from SB and attempt to compile SB, I receive a compile error stating that C.dll can not be over-written because it is in use by another process (the instance of devenv.exe which is running SA).
This does not make sense to me because after compiling C to C.dll and copying to the output directory of A, Visual Studio should release the lock on the file.
I have verified (via the Modules window in SA) that the version of C.dll loaded is the one which has been copied to the output directory of A.
This started occurring yesterday when I began using Visual Studio 2015 (instead of Visual Studio 2013).
Does anyone have any ideas? My current solution is to run SA via CTRL-F5 (start without debugging), but this becomes annoying when I want to run SA and SB in debug mode simultaneously.
Thanks.
UPDATE
I did some research into why the "Edit and Continue" feature could cause the described behavior, and according to this page https://msdn.microsoft.com/en-us/library/ms164926.aspx> Edit and Continue allows one to make source code modifications while in a debugging session and have the results take effect without stopping debugging, recompiling, and restarting the debugging session (what a gnarly problem that must have been). With that feature enabled, Visual Studio might be required to recompile any dependent DLL's at any time which explains the lock.
I had the same problem. I changed my VS2015 settings and it seems the problem is gone:
disabled Options\Debugging\Edit and continue
-Options\Sourcecodemanagement from TFS to none-
-disabled Options\Debugging\Diagnostictools while debugging-
Not sure wich one caused the locking, but i suspect the diagnostictools wich I did not have in VS2013.
(The settings names I translated from German to english, don't know if it is exactly how they are called in english VS version.)
Edit:
As researched by Shea it was the Edit-And-Continue feature that locked the DLL.
in my case this was "Panda free Antivirus" Who was watching on the dll of the "C" project and this caused the error: "the process cannot access the file because it is being used by another process"
I had the same problem and none of the other recommended solutions I came across while searching the interwebs worked for me. Finally after "repairing" Visual Studio 2015 Enterprise, I tried launching Visual Studio in safe mode: devenv.exe /SafeMode
In safe mode I was able to finally build my solution, and when I started again without the switch, I was prepared to shut off extensions one by one until I found which one was the culprit. Luckily that was unnecessary and subsequent builds went off without a hitch.
In my case, the .pdb file was locked. This is not the same as the .exe getting locked as it should be when debugging.
Assuming it's just the .pdb, simply move it to a new folder (I dragged and dropped). Oddly enough, it cannot be deleted, but it can most certainly be moved! Once the .pdb file was gone, the assembly was able to compile again.
The alternative solution (and probably the least convenient) involves closing out of the project entirely, then opening it again (the .pdb file magically unlocks!).
Edit:
After happening a second time, moving the file did not work; it appears restarting the project is the only reliable way to go.
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.
When opening an MVC4 C# web project in Visual Studio 2013, the IDE reports the error "The type or namespace name '_' could not be found (are you missing a using directive or an assembly reference)", but the project builds and runs without any errors. Furthermore, intellisense does not include the project namespace.
The "missing" reference is to files within the same project.
for example; the web project namespace is "webproject.com", and references in a controller files to "webproject.com.models" is underlined in red with the error above.
I have checked the following:
All Solution projects are configured to use the same Target Framework(.Net 4)
web.config in the Views folder contains the namespace in the system.web.webPages.razor section
cleaned and rebuilt solution
deleted all bin and obj content
deleted .suo and .csproj.user files that were created by VS2010
The only way that I can get rid of these errors being reported in VS2013 is to unload then reload the project.
When opened in Visual Studio 2010 I do not get these problems.
I have the same issue.
ALthough the project compiles correctly, the code editor shows an error The type or namespace name '_' could not be found (are you missing a using directive or an assembly reference).
THere is one workaround. Just delete the *.SUO files and re-open the solution. THen for this only Session it works. Unfortunately after closing and reopening the solution the issue is back again. VS 2012 works fine.
Seems to be a bug in VS 2013....
My solution, when I encountered the problem with VS 2013 Express edition was to simply unload the offending project and reload. Opening the SUO or Project file and making changes had not affect.
Try to unload the project in VS2013, then right click the node and select edit "projectname.csproj". Check the individual references they might point to somewhere strange.
EDIT: the csproj file is an xml file and the references are located under Project -> ItemGroup -> Reference
I had the same issue.
It's a VS 2012 solution with different projects.
Search for all *.suo files and deleted them.
Rebuild and reopen Visual Studio.
There's a known issue with Web Application projects when bound to a TFS server that sounds like this issue. This occurs when the following TFS setting option is checked:
Options -> Source Control -> Environment -> Get everything when a solution or project is opened.
Disabling this option resolves the problem.
thanks,
Miguel Lacouture
[MSFT]
Same issue, on project reference.
I opened the referenced project file (*.csproj) with a text editor and did some cleanup:
1) reset these properties' values:
<PublishUrl>publish\</PublishUrl>
<InstallFrom>Disk</InstallFrom>
<UpdateEnabled>false</UpdateEnabled>
<IsWebBootstrapper>false</IsWebBootstrapper>
<TargetFrameworkProfile />
2) removed dirty platform/configurations:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'x86|AnyCPU'">
...
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'x86|x86'">
...
Now I can compile without any issue.
Glad to share it with you! :))
Same issue. Opening the project's properties and making a change to the name (or any value) and then rebuilding seems to have resolved it.
I have just had this problem and none of the solutions here helped. I fixed mine by doing a repair of Visual Studio (An option when you select to uninstall the program). Hope this helps someone
I had same issue when I added a new class file ( e.g. MyClass.cs) and called it in some other C# code places. For some reason VS did not add that new class file to my working project folder (not seen in VS, but seen in Windows File Explorer). And, hence, the compile path for new class file is not included in the compile section of my project file (e.g. MyProject.csproj). So to solve this problem, First, right click on your working project > Add > Existing Item ... > Select your new class > OK.
Then, check the project file (*.csproj) and make sure a new element is inserted in the compile section such as:
Finally, rebuild your project and the problem should be solved.
Another reason for this issue is the project, I had long ago with VS, is my other project was set up with Client Profile as its target framework. So, to solve the issue: Right click your project in VS > Properties > Application tab > make sure Target Framework option is not Client Profile. You should change all projects in your solution to the same framework version AND all of them must not have Client Profile option.
Microsoft just released a new security update to be automatically applied to machines configured to use Microsoft Update.
Unfortunately, some ASP.NET MVC 3 and 4 VS projects can no longer build after the update is applied. These projects will fail with the following error:
"Could not locate the assembly "System.Web.Mvc,Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL"
My project also had the error "The type or namespace name 'System.Web.Mvc' could not be found (are you missing a using directive or an assembly reference)". Installing the latest version of Microsoft.AspNet.Mvc solved my problem. See the following article from Microsoft for more info:
http://blogs.msdn.com/b/webdev/archive/2014/10/16/microsoft-asp-net-mvc-security-update-broke-my-build.aspx
Unloading and then reloading the project worked for me.
I tried to convert a project that relies on the vjs runtime to vs2010, but it errors out when trying to run.
It's giving the error that "Could not load file or assembly 'vjslib' or one of its dependencies. An attempt was made to load a program with an incorrect format."
I reinstalled the vjs runtime, but it didn't seem to help.
Is there any way to get get .net 4 to work with this?
Very simple solution - Calling J# code from .NET 4.0
You take control and load it first supplying an explicit path. Then next time it's needed, it already knows the path (or it's already loaded in the AppDomain).
You will need to use LoadLibrary function, so import the pinvoke reference:
[DllImport("kernel32", SetLastError = true)]
static extern IntPtr LoadLibrary(string lpFileName);
The on load (either Main function in Console/WinForms or in Global.asax Application_Start):
if (Environment.Version.Major >= 4)
{
string folder = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), #"..\Microsoft.NET\Framework\v2.0.50727");
folder = Path.GetFullPath(folder);
LoadLibrary(Path.Combine(folder, "vjsnativ.dll"));
}
I have downloaded Microsoft Visual J# Version 2.0 Redistributable Package from http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=4712 and installed it.The issue is resolved.
I got this to work by copying C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vjsnativ.dll (for 64 bit Microsoft.NET\Framework64\v2.0.50727\vjsnativ.dll) to my application's debug/release directory.
I suspect Microsoft will need to release another j# redistributable package to work with .net 4.0. Meanwhile, this work-around does a fine job.
The only way I could get it to work was to copy the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\vjsnativ.dll to the C:\Windows\Microsoft.NET\Framework\v4.0.30319 folder. See http://community.microfocus.com/borland/managetrack/starteam/w/knowledge_base/17108.error-unable-to-load-dll-vjsnativ-the-specified-module-could-not-be-found-exception-from-hresult-0x8007007e.aspx
To add to the existing answers, I found that the solutions didn't work for me.
First thing I did was to repair the Microsoft Visual J# 2.0 Redistributable Package -SE (x64) using Windows Control Panel (Just right click and click repair). This was in case I did any damage in my previous attempts to fix the problem.
I had already implemented the solution provided by David Thielen.
1 Extra step closed the deal for me (solved the problem):
Copy "vjscor.dll", "vjslib.dll" and "vjsnativ.dll" from C:\Windows\Microsoft.NET\Framework64\v2.0.50727 To C:\Windows\Microsoft.NET\Framework\v2.0.50727
So basically the Microsoft package placed the correct dlls into the 64-bit .NET framework and I had to manually move them into the 32-bit folder which is then copy-pasted into my solution folder by David Thielen's solution (above).