I am building and Advantage AEP to run on a Win 2008 server (64bit). I'm developing the AEP in VS2008 on a 32-bit machine. Building for Any CPU and testing using Local Server works just fine.
When I Build for x64, VS2008 gives this error.
Error 1 File "C:\Projects\Experiment\AdvantageTrigger1\bin\x64\Release\ADSUpdateTriggerHX.dll" is not a valid assembly. AdvantageUpdateTriggerHX
How do I build a valid assembly?
I can register the assembly on the target server (regasm in Framework64), and I see it in the Registry. It does not show up in the Trigger Dialog Browse. I even GACed it, but that didn't help.
Thanks,
Tim
Visual Studio runs as a 32-bit process and only calls the 32-bit regasm.
This KB item from the Advantage Developer Zone should help: http://devzone.advantagedatabase.com/dz/content.aspx?Key=17&RefNo=100616-2328
(note, copy/paste of solution from KB item)
In the project settings uncheck "register for com interop" in the build settings. Then add a post-build command described in this MS KB item: http://support.microsoft.com/kb/956933
The command is: "%Windir%\Microsoft.NET\Framework64\v2.0.50727\regasm" "$(TargetPath)"
Related
I am working on .Net core Microservices. I installed Docker Toolbox containing docker cli and kitematics. After that i created a simple (.Net core) web api project in visual studio 2017 and also enable docker support.
But when i hit F5 to run the program it shows following error and doesn't run.
Visual Studio Container Tools requires Docker to be running before building, debugging or running a containerized project.
Please review the attached image.
Visual studio error on running the project
If i build and run the project using docker cli, it's working. The problem is with visual studio 2017.
In my case I had an erroneous reference in Dependencies > Packages to Microsoft.VisualStudio.Azure.Containers.Tools.Targets
Removing the reference fixed the error.
The problem occurs because Visual studio container is unable to connect to docker for windows and solution for this is to open the visual studio 2017 from Docker CLI using following command.
/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Community/Common7/IDE/devenv.exe C:\\PATH\\TO\\MY\\SOLUTION.sln
Here:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
is the location of my devenv.exe file and 2nd parameter
C:\\PATH\\TO\\MY\\SOLUTION.sln
shows the path of solution file.
For further details of this solution, click Here.
In my case, this issue was caused by a disabled BIOS Virtualization. To enable Virtualization, see here. In order to check whether Virtualization is already enabled, start Task Manager > Performance > find Virtualization. If you are hosting your docker container application in full feature IIS, make sure you start Visual Studio as an Administrator.
I was getting the same error when I was trying to rebuild my solution after changing my .Net Core 2.0 application to .Net Core 2.2. As I reset my windows, there was no docker installed on my machine. To fix this all I had to do is to install the docker for desktop as I wanted to containerize my applications.
Once you install the Docker, it will ask you to enable Hyper-V and Container features. By clicking the Ok button in the pop up as preceding, will enable this features for you.
Your computer will be restarted automatically and once it is done, you should be able to see that the Virtualization is enabled in the task bar.
After this I was not facing this error.
Check shared folders inside the default virtual machine setting in Virtual box to make sure you shared the disk where you project located. By default shared only C:\Users. So alternatively you can move your project somewhere inside C:\Users folder (for example in Desktop folder)
I was facing the same issue and I resolved it by switching to IIS Express instead of Docker in debug menue on visual studio 2017
I have Jenkins CI server which builds various .net projects. The server is on Virtual Machine, connected to ActiveDirectory and Jenkins is running in the context of domain user which is also a local administrator.
Software used:
Windows 10 Professional
Visual Studio 2015 14.0.25431.01 Update 3
Jenkins 1.625.3
Solutions are build using devenv.com (currently msbuild is not an option), e.g.:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com" "xxxxx.sln" /rebuild "Release|Any CPU"
My issue is, that quite often I receive an error, just after running devenv.com:
Microsoft Visual Studio has detected a configuration issue. To correct this, please restart as Administrator. For more information please visit: http://go.microsoft.com/fwlink/?LinkId=659046Build
It started to happen after one of Windows 10 updates. I found out, that when someone is log in to build server with the remote desktop using the same domain account, the builds run OK. After logout, the builds run OK for some time and then the errors are back.
Any clue what's going on?
It may be related to this apparent bug in a recent Windows update:
Connect: Visual Studio 2015 and SSMS 2016 RTM (VS 2015 shell) not running under "Run as different user" on Windows 10 Anniversary, Windows 2016 CTP 5
UPDATE 2017-09-08
As #Florian points out, the above link is broken. I can't even find the Connect issue cached on Google, Bing or archive.org.
The Connect issue Unable to start SSMS as another user (cached copy on archive.org) makes me think it would be worth checking whether the problem resolves after updating Windows 10 to 1703 (Creators Update) and ensuring that April 25, 2017—KB4016240 (OS Build 15063.250) has been applied. If this works, anyone running Jenkins on Windows Server 2016 will have to wait for Microsoft to publish 1703 and KB4016240 (or equivalent) for that OS.
Excerpts from Connect page "Unable to start SSMS as another user". I have bolded the error details, which match those in the original question (except for the LinkId in the supplied URL) even though the product is SSMS rather than VS:
Version: SQL Server 2016 CTP3
Operating System: Windows 10
Steps to Reproduce:
Right-click SQL Server Management Studio, select "More", then "Run as
a different user"
Actual Results:
Error message: "This task requires the application to have elevated
permissions" with two options: Restart under different credentials,
and Cancel the task and return to Microsoft SQL Server Management
Studio. Pressing either option closes the window with no further
result. Error information is:
Microsoft SQL Server Management Studio has detected a configuration issue. To correct this, please restart as Administrator. For more information please visit: http://go.microsoft.com/fwlink/?LinkId=647011.
When I go to that page and try the fix suggested there, I can't find
ieproxy.dll. The fix is for Windows 7 / Internet Explorer 8, and I'm
on Windows 10 with Internet Explorer 11, so that may be why it's not
there.
[...]
Posted by Microsoft on 4/28/2017 at 6:26 PM
Hi Jake, It turned out that this issue has been resolved (on the Windows side) very recently - like 3 days ago :)
If you are running Win10 "1703", just make sure you get the latest
updates (specifically, KB4016240) and you should be able to run
ssms.exe using "runas" just fine. This will work with any version of
SSMS.
Currently, the fix is not available on older versions of Win10 (e.g.
1607) or WS2016 (also 1607).
Thanks,
-Matteo
[...]
Posted by Microsoft on 4/27/2017 at 7:35 PM
Hi Jake, Yes, we are aware of this issue (in Windows 10).
We've engaged with the Visual Studio and Windows folks (which is there
the issue is) and hopefully will have a way to fix this issue in SSMS
(you should not need an updated SSMS, just an update in Windows 10).
I'm going to keep this issue open until I have more concrete updates
on it.
Thanks,
-Matteo
If the Windows updates do not solve the problem or are not available to you, I would suggest trying repair operations on Windows as well as Visual Studio.
I'm running into the same error after updating my Windows 10 to 1607, in that I cannot run Visual Studio as a different user. I'm not building solutions at the time though, but still running the VS program as I think you would be calling.
Using this command: runas /netonly /user:domain \ account devenv.exe
as outlined here Unable to launch Visual Studio 2015 as a different user works for me. Not as convenient but does the trick.
I'm trying to get Dotfuscator Pro 4.13 to run between the unit tests and creation of installation package. The buildserver that we use is Jenkins 1.487 on Windows Server 2008 R2.
The command line for dotfuscator is very simple, i use /q and point out an xml configuration file. it works like a charm when i manually run the exact command from the commandline.
But when the same commands are executed by Jenkins the following error is logged:
Use of this software implies acceptance of accompanying license
agreement.
LICENSED TO:
SERIAL #:
You must first accept the end user license agreement before using Dotfuscator.
For some reason Dotfuscator cant read the licensing information when it's ran by Jenkins. I cant find any information about this but something tells me that this is related to the user that Jenkins is executed under. What am i missing?
As i thought it was something user related. this problem comes from that the user the Jenkins job is ran under has never accepted the Dotfuscator user agreement. There are two ways to resolve this:
Either you log into the machine with the user that is running the automated build and launch the Dotfuscator GUI and accept the license agreement
Or you can copy the following files:
C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml
C:\Users{user that installed/accepted agreement}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg
C:\ProgramData\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.dat
into the installation directory of dotfuscator (default is C:\Program Files (x86)\PreEmptive Solutions\Dotfuscator Professional Edition 4.13.0).
I had a similar problem using Team Foundation Build Service running under Windows Server 2012.
According to Dotfuscator's tech support:
To resolve this you will need to move the following files:
C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dfusrprf.xml
C:\Users{User that installed dotfuscator}\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition\4.0\dotfuscator.cfg
Into the same folder on the user account that is running the automated build.
I was running my build service under NT AUTHORITY\NETWORK SERVICE. After some searching I found their home directories:
%systemroot%\ServiceProfiles\NetworkService
which usually translates as:
c:\Windows\ServiceProfiles\NetworkService
My company runs an old application written in delphi. A simple com server which serves some database for some computers. I have to run the server once in every computer to register the com interfaces and it have been working since the ancient days of whatever in windows xp.
Using windows xp I have never had a single problem but in windows seven the class just won't register and no matter what I try(I tried exporting the register keys) when I open the client I will still get the error "Class not registered".
Any advice? Plz save my Christmas.
My COM servers, both EXEs and DLLs, are written in BCB6 (as opposed to Delphi) on 32-bit XP and they work just fine when installed on 64-bit Windows 7. You just have to make sure that you run their installation code from an elevated process, that's all. Open an instance of cmd.exe with the "Run as administrator" option, then navigate to your COM server's folder and run it with the /INSTALL parameter (for EXEs) or the 32-bit version of regsvr32.exe (for DLLs) from the WOW64 system folder.
Has anybody managed to get Tomcat to run as a service on Win2008 64bit? I need it for a 3rd party component that my site relies on. It works fine otherwise, but I just can't get it to run as a service. I've tried all the googling I can, and experimented with various 64bit tomcat.exe / tomcatw.exe without success. Upgrading to Tomcat 6 didn't help either.
I'm running Java 1.5 64bit.
Download apache-tomcat-6.0.30-windows-x64 version.
Extract to c:\Tomcat6
open command prompt run as Adminstrator
and go to Tomcat6\bin directory and run from command prompt>service install
Tomcat6 will install as Windows Service.
again go to Tomcat6\bin and open tomcat6w.exe run as administrator and modify your changes.
it works cool.
Download the latest builds. Your issue was the 64 bit procrun.exe/tomcatw.exe wasn't provided. The newer installers for Tomcat 5.5 and Tomcat 6 include both 32 and 64 bit and deploy the appropriate one
Extracted from http://www.openlogic.com/wazi/bid/188180/
While the Java components of Tomcat run happily under a 64 bit JVM, the installers that build the Windows service are 32 bit executables and won't work correctly under 64 bit Windows operating systems.
Fortunately, the Tomcat team has put together 64 bit versions of these executables, although they only include them in the source distribution for each version of Tomcat. If you've already installed a copy of Tomcat, here's how to update the executables:
1) Download and extract the source distribution for your version of Tomcat from OLEX
2) Find the directory tomcat-X.X.XX-src/connectors/procrun/bin/amd64/
3) Copy the executables from the above directory into the tomcat-X.X.XX/bin, overwriting the 32 bit versions
4) Run the command service.bat install. This will install the service under the displayed name Apache Tomcat (the service name will be Tomcat5)
It worked to me! And I was looking for this solution for a while...