I've got a solution in Visual Studio that includes a Dotfuscator project. The exact same code base builds and obfuscates correctly on another machine (my old laptop), but not on my newly setup laptop. Of course we let our support contract expire since this is used on a legacy project.
The output during the build is:
8>Compiling Project MyAppObfuscation ...
8>Dotfuscator Professional Version 4.41.1.9417-95d9eec7a
8>Copyright 2002-2019 PreEmptive Solutions, LLC All Rights Reserved.
8>Use of this software implies acceptance of accompanying license agreement.
8>Build machine license. This software may be used on binaries for general release.
8>
8>Your protection is out of date. Learn more at https://www.preemptive.com/keep-your-protection-up-to-date?product=dotfuscator&sku=pro&version=4.41.1.9417. Upgrade at https://www.preemptive.com/products/dotfuscator/downloads.
8>
8>Loading Assemblies...
---several of these lines---
8>Running ...\ildasm.exe /OUT=...\MyApp.exe.il /TEXT /NOBAR /RAWEH /QUOTEALLNAMES /UTF8 /LINENUM /FORWARD "...\MyApp.exe"
8>
--- immediately followed by: ---
8>Encountered - at line 18065, column 26.
8>Was expecting one of:
8> <FLOAT64> ...
8> "float64" ...
8> "float32" ...
8> <INT> ...
8> "(" ...
8>
8>Build Error.
8>MyAppObfuscation build failed.
Has anyone encountered this? I'm inclined to believe it's something on the new machine, but if anyone has tips about diagnosing this I would appreciate it.
Thanks!
Edit: Just wanted to add the same error happens in Visual Studio and the Dotfuscator Professional Config Editor.
Edit 2: Upon further inspection, the folder listed in the /OUT parameter of ildasm doesn't contain a .il file for the last ildasm command. The output folder for the assemblies prior to the .exe DO have a .il file. So, I thought ildasm might be failing on the .exe, but I can copy the command into a command prompt and it runs correctly and creates an .il file as expected. So, why would ildasm not work when run from Visual Studio, but would work from the command line -- and only for one assembly / exe in the project?
The mystery grows...
Solved it! I opened Visual Studio Installer on both the old and new machine to compare what features were installed on the old one vs the new one. Most notably, one of the missing features on the Individual components tab was an older .NET Framework SDK (4.6.1 in my case) and an older Windows 10 SDK (10.0.17763.0 in my case).
I hope someone else finds this helpful.
Related
While building the Windows environment for OsQuery (on my Windows 10 VM) from their website(link: https://osquery.readthedocs.io/en/stable/development/windows-provisioning/), I am getting the msb1009 error during the phase where I have to run the tools\make-win64-binaries.bat command. I get the following result after running that command:
CMake Error at CMakeLists.txt:402 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1009: Project file does not exist.
Switch: VCTargetsPath.vcxproj
Exit code: 1
-- Configuring incomplete, errors occurred!
See also "C:/Windows/System32/osquery/build/windows10/CMakeFiles/CMakeOutput.log".
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1009: Project file does not exist.
Switch: osquery.sln
[-] osquery build failed.
I have been trying to make the osquery.sln file using that command and have looked online for solutions but without any success. Any help would be much appreciated!
Thanks in advance
Edit: Here is the output of running tools\make-win64-dev-env.bat and tools\make-win64-binaries.bat
tools\make-win64-dev-env.bat
tools\make-win64-dev-env.bat (contd..)
tools\make-win64-binaries.bat
Could you paste the full output of running the tools\make-win64-dev-env.bat and tools\make-win64-binaries.bat? Also have you tried closing out your shell and re-opening, or even worse -- reboot the system?
I ask because, as you note, it seems like the solution file never gets generated, which usually means there was either a missing dependency during provision, or some other issue when the script first ran. On first provision it's typically the case that a system reboot is needed, as Visual Studio community typically requires one. Further, we set a few shell environment variables that are leveraged during the build process, however those are supposed to be set at the end of the provisioning script.
Also feel free to hit us up in our Slack and check out the #windows channel :)
After a lot of code reading, researching online and trial and error, I found out that after a clean OS install, one would need to install git and then immediately clone the osquery repository on the user desktop rather than System32. This worked fine, at least for me. Just make sure to switch directories when opening command line with administrator mode.
I've been working on this particular issue for a couple weeks now, and I'm exceedingly frustrated. As such, I'll give all the information I can and hope for the best.
My team is working on building a new application. Here's the alphabet soup:
.Net 4.5.1
nHibernate 4.0.0.4000 with FluentNHibernate 2.0.3.0
Oracle 11g (Oracle.DataAccess 2.112.1.0, which has Copy Local set to true)
Visual Studio 2013 is the IDE
Windows 7 Professional
I am compiling the application as a 32-bit app, and I have confirmed that I have the 32bit version of Oracle installed.
We've written some tests for the NHibernate mappings, which we run through MSTest. When we run these through Visual Studio's test explorer, they all run properly and pass. The application itself also properly compiles and deploys as it should. We've verified the tests are running properly by checking the database between steps, so we're fairly sure that the tests themselves aren't the problem.
When we run MSTest through the command line though, we receive the following error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Unable to find the requested .Net Framework Data Provider. It may not be installed..
I've tried reinstalling Oracle to no effect. I've tried checking the machine.config file for errors (as suggested in other posts here on SO) and found none.
Our Fluent configuration is as follows:
OracleDataClientConfiguration.Oracle10
.ConnectionString(connectionString)
.Driver("NHibernate.Driver.OracleDataClientDriver")
.ShowSql()
.FormatSql();
The code I'm running on the command line is the following:
(cd to the directory where the test .dll is)
>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:MyTests.dll /test:UnitTests
I feel like I'm missing something here. Any ideas?
Update: Solution Found
So here's a weird one. I followed Fran's solution below and installed the Oracle.ManagedDataAccess package and changed the NHibernate driver in our configuration above to NHibernate.Driver.OracleManagedDataClientDriver. As per our quick comment-discussion, this lead to a new error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleManagedDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Configuration.ConfigurationErrorsException: Failed to find or load the registered .Net Framework Data Provider
Fran then lead me to another SO question which encouraged me to check the Oracle configuration piece by piece. What better way to do this than create a test?
var x = new OracleConnection(connectionString);
x.Open();
Assert.IsTrue(x.State == System.Data.ConnectionState.Open);
x.Close();
Assert.IsFalse(x.State == System.Data.ConnectionState.Open);
In my quick attempt to run this test, I ran the whole collection of UnitTests with the script I'd mentioned above. Low and behold, every test passes!
Doing my due diligence, try the following
I comment out that test, clean, rebuild, and run the script again. Failures.
I return to the old Oracle driver and add that new test in. Clean, Rebuild, Run. Failures.
Add back the new Oracle driver, make sure the new test is still in. Run tests OTHER than the new test. Passes.
For some reason, the combination of the new driver and explicitly referencing it in a test seems to have resolved the issue. I'm open for any theories as to why, but I bet that qualifies as a new question.
I would stop using the bit specific version of the oracle drivers and move to the managed driver (https://www.nuget.org/packages/Oracle.ManagedDataAccess/). It is bit agnostic, and doesn't require you to install the Oracle client at all.
I actually found the solution to the problem, and it all has to do with how the Oracle.DataAccess.dll file gets loaded at runtime (Disclosure: I work with wadeb on the same project).
It seems that Oracle.DataAccess.dll was being searched for in every location on the server except the build output folder in the Jenkins workspace, and as such was pulling the DLL file from the GAC.
One of the file paths used to find the DLL file is the folder in which the "current executable" is located. In our case, the "current executable" was mstest.exe. Copying the Oracle.DataAccess.dll file to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE did the trick.
Did it work. Yes.
Was it a hack? Absolutely -- but now it works without having to upgrade to the managed Oracle drivers.
Our servers weren't using an Oracle client that worked with the managed driver, and it wasn't acceptable to have a broken continuous integration build until servers get upgraded.
I have got just the same error and I switched my tests to x64 and it works like a charm now:
Current situation:
One of our products exported via the Eclipse Product export wizard does no longer run, if the produced .exe is run directly. Unfortunately no error message is shown, the program just stops. I assume that no plug-in is loaded at all.
Interestingly the product runs in the following cases:
the created .exe is executed in the developer mode:
in cmd with MyApplication.exe -dev
in Eclipse with Launch an Eclipse application
my colleague, who uses the same code, can export the product and run it directly
the .exe, created by me, can be run on my colleague's PC and another PC
Furthermore I can build and run the other product as usual. Win 7 and Java 7 are installed on the three PCs.
Log:
There is a Log file in \configuration:
!SESSION 2015-02-05 18:03:17.765 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.7.0_65
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
Command-line arguments: -os win32 -ws win32 -arch x86
!ENTRY org.eclipse.equinox.ds 1 0 2015-02-05 18:03:19.481
!MESSAGE Could not bind a reference of component com.company.common.utils.Zipper.
The reference is: Reference[name = LogModelProvider, interface = com.company.common.service.ILogModelProvider,
policy = dynamic, cardinality = 0..1, target = null, bind = setLogModelProvider, unbind = unsetLogModelProvider]
I am not sure what the message means, but it also appears when the application is running in Eclipse. Therefore I ignored it.
There is no log file in \workspace. The folder .metadata does not exists.
What might have gone wrong:
The PDE build and export used to work, till I wanted to use Tycho as build system. Therefore I made the needed changes and finally I could build the two projects. Although the projects showed the same symptoms as described above (one worked, the other not). Therefore I created a SVN branch, committed every change and switched back to the trunk, to be back in the starting position. But the symptoms were not gone. Therefore I assume that I must have changed some setting, which causes the problem.
What I tried:
Basically I checked if the code and settings were back in the original state. I also switched the Eclipse workspace and imported the necessary plug-ins again. I also rebooted the PC once or twice.
Question:
Did anybody already have a similar behavior? Any hint is welcome.
(I know that my problem description is vague, sorry for that.)
I was using msbuild build my sln and get error message "couldn't find 'AxImp.exe' which already exists under %Program files (x86)%\Microsoft sdks\windows\v8.1A. but seems it find sdk from v8.0A, output info point out the error was in Microsoft.Common.targets file(code see below). I didn't found where the "TargetFrameworkSDKToolsDirectory" was defined, anyone can help me?
environment: winblue(4.5.1 sdk v8.1A) without visual studio.
<ResolveComReference
TypeLibNames="#(COMReference)"
TypeLibFiles="#(COMFileReference)"
ResolvedAssemblyReferences="#(ReferencePath)"
WrapperOutputDirectory="$(InteropOutputPath)"
IncludeVersionInInteropName="$(IncludeVersionInInteropName)"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
StateFile="#(_ResolveComReferenceCache)"
TargetFrameworkVersion="$(TargetFrameworkVersion)"
TargetProcessorArchitecture="$(ProcessorArchitecture)"
NoClassMembers="$(ComReferenceNoClassMembers)"
Silent="$(ResolveComReferenceSilent)"
EnvironmentVariables="$(ResolveComReferenceEnvironment)"
**SdkToolsPath="$(ResolveComReferenceToolPath)"**
ExecuteAsTool="$(ComReferenceExecuteAsTool)"
MSBuildArchitecture="$(ResolveComReferenceMSBuildArchitecture)"
ContinueOnError="$(ContinueOnError)">
<**ResolveComReferenceToolPath** Condition="'$(ResolveComReferenceToolPath)' == ''">$(**TargetFrameworkSDKToolsDirectory**)</ResolveComReferenceToolPath>
Depends on the version and platform you're targeting, but latest is at C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.NetFramework.CurrentVersion.props, follow your imports, i.e. <Import Project=".targets" />. To get the values run MSBuild with /v:diag and all evaluated properties will be dumped and the start.
what ended up working for me was installing:
Windows Software Development kit (SDK) for windows 8
even though I'm on widows server 2016
https://developer.microsoft.com/en-us/windows/downloads/windows-8-sdk
I guess the clue was in my error:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2428, 5): error MSB3086: Task could not find "LC.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.