I'm getting a null when running MSBuild with the /t:TransformAll target in a .csproj:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TextTemplating\Microsoft.TextTemplating.targets(396,5): error : Running transformation: System.NullReferenceException: Object reference not set to an instance of an object.\r [C:\IDB-Git\IDB.Middleware\IDB.MW.Domain\IDB.MW.Domain.csproj]
No clue about what to do now. Is it a bug? How could I workaround this?
The following is an extract of the line 396 of Microsoft.TextTemplating.targets and its context:
<Target Name="ExecuteTransformations" DependsOnTargets="CreateT4ItemLists">
<TransformTemplates
TemplatesToProcess="#(T4TransformInputs)"
IncludeFolders="$(IncludeFolders)"
DirectiveProcessors="#(DirectiveProcessor)"
AssemblyReferences="#(T4AssemblyReference)"
ReferencePaths="#(T4ReferencePath)"
TrackerLogDirectory="$(TrackerLogDirectory)"
TrackFileAccess="$(TrackFileAccess)"
MinimalRebuildFromTracking="$(TransformOutOfDateOnly)"
OverwriteReadOnlyOutputFiles="$(OverwriteReadOnlyOutputFiles)"
ParameterValues="#(T4ParameterValues)"
>
You probably have a null reference in one of your templates being transformed. The TransformTemplates task will just fail and bubble up any exceptions from the transform of a template fails. The best way to find the culprit is to run the target one at a time for each template you have.
If you really want to validate that the TransformTemplates isn't to blame then you should run MS Build with diagnostic logging and ensure all of the TransformTemplates parameters have sensible values.
Related
I have created a solution using Visual Studio 2017 which consists of a Windows Service C# Project and an InstallShield 2016 Basic MSI Project.
The InstallShield project has a single component added. This component has a number of files added using the Component->Files->Add File... (below)
Note the use of VSSolutionFolder.
Now when I open the InstallShield project (.ism) using InstallShield 2016, and build the project, I get the following build errors:
Loading File table
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb"
ISDEV : error -6103: Could not find file "<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config"
Building MsiFileHash table
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
ISDEV : error -6271: File <VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config not found. An error occurred building the MsiFileHash table record for this file. Verify that the file exists in the specified location.
Adding instance transforms to substorage...
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.exe'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe.config' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.exe.config'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.pdb' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\ACMECorp.App.Service.pdb'
ISDEV : error -1007: Cannot copy source '<VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\App.config' to target 'E:\Installshield\WebDeploy\Windows Services\ACMECorp.App.Service\ACMECorpSetup\ACMECorpSetup\Default Configuration\Release\DiskImages\DISK1\program files\ACME Corp\ACME Corp Service 0\App.config'
In Media Path Variables, there is a VSSolutionFolder with a value UNDEFINED.
I cannot change this Current Value - the UI does not allow it. Defined Value cannot be changed and Test Value doesn't seem to do much.
I have the project saved as xml but I only see the VSSolutionFolder referenced in file paths like so:
<row>
<td>acmecorp.app.service.exe</td>
<td>ACMECorpServiceFilesComponent</td>
<td>ACMECO~1.EXE|ACMECorp.App.Service.exe</td>
<td>0</td>
<td/>
<td/>
<td/>
<td>1</td>
<td><VSSolutionFolder>\ACMECorp.App.Service\bin\Debug\ACMECorp.App.Service.exe</td>
<td>1</td>
<td/>
</row>
Is there a way of setting VSSolutionFolder in InstallShield? Or is there some way of fixing this.
Ideally I want it to just load in Visual Studio and InstallShield without having to muck about with source locations - yes I can remove the files and re-add, but that is not the question (if I had a larger solution it wouldn't be acceptable I don't think).
Personally I recommend keeping your application code and your installer code in two different solutions. There are several reasons including:
1) A new version of VS comes out that IS doesn't support yet and you don't want to be held back.
2) Simplifies project dependencies and build order relationships. Build your app code first then build your installer code second.
3) Depending on where you are in the agile/devops spectrum you might want to keep your peanut butter and chocolate separate.
In this scenario I use postbuild xcopy commands and msbuild publish profiles to stage my application code to a "Deploy" directory in the workspace in the directory that your .ISPROJ and .ISM lives. From there InstallShield simply uses the standard ISPROJECTDIR path variable reference. Now you don't have to deal with the complexities of project output references. You have a nice model defined of what your deployed application should look like.
Try overriding the path variable. You can do this either with external approaches like iscmdbld -L... or with the Release Configuration property Path Variable Overrides. (Note that building the solution with MSBuild should already just work.)
If there are problems overriding VSSolutionFolder itself, you can change your file links to use a new standard variable that is defined to use <VSSolutionFolder> as its default path, but will definitely allow you to override it.
I have a UWP app that compiles successfully if I have UseDotNetNativeToolchain off. But when I turn it on, it gives me the cryptic error:
Internal compiler error: Object reference not set to
an instance of an object. UWPApp C:\Program Files
(x86)\MSBuild\Microsoft.NetNative\x86\ilc\IlcInternals.targets 887 Build
This is all it gives me. What could be causing this? How can I drill down on this.
Using VS2015
Here is the full build output in case that helps:
https://gist.github.com/shannah/e24fe8456313fb9ad98577c9a812f357
The solution to this problem was to disable optimization in a few assemblies I was using in the Default.rd.xml file. E.g.
<Assembly Name="IKVM.OpenJDK.Core" Dynamic="All" DoNotInline="true" DoNotOptimize="true"/>
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.
I am trying to migrate one of projects earlier in VS2008 to VS2010. On building I get the following error
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(317,7): error MSB4094: "hdxBinding.idl;hdxBlinking.idl;HDXCommandObject.idl;hdxds.idl;HSCProcessStatus.idl;HSCSelectableWindow.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
On clicking this error, it takes me to the line Source ="#(Midl)" inside C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets file
A Code Snippet in Microsoft.CppCommon.targets file:
<ItemGroup>
<Midl Condition="'#(Midl)' != ''">
<MinimalRebuildFromTracking Condition="'$(BuildType)' != 'Build' or '$(ForceRebuild)' == 'true'">false</MinimalRebuildFromTracking>
</Midl>
</ItemGroup>
<PropertyGroup>
<MidlToolArchitecture Condition="'$(MidlToolArchitecture)' == ''">$(DefaultToolArchitecture)</MidlToolArchitecture>
</PropertyGroup>
<MIDL
Condition ="'%(Midl.ExcludedFromBuild)'!='true'"
Source ="#(Midl)"
AdditionalIncludeDirectories ="%(Midl.AdditionalIncludeDirectories)"
AdditionalOptions ="%(Midl.AdditionalOptions)"
ApplicationConfigurationMode ="%(Midl.ApplicationConfigurationMode)"
ClientStubFile ="%(Midl.ClientStubFile)"
CPreprocessOptions ="%(Midl.CPreprocessOptions)"
DefaultCharType ="%(Midl.DefaultCharType)"
DllDataFileName ="%(Midl.DllDataFileName)"
EnableErrorChecks ="%(Midl.EnableErrorChecks)"
ErrorCheckAllocations ="%(Midl.ErrorCheckAllocations)"
ErrorCheckBounds ="%(Midl.ErrorCheckBounds)"
ErrorCheckEnumRange ="%(Midl.ErrorCheckEnumRange)"
ErrorCheckRefPointers ="%(Midl.ErrorCheckRefPointers)"
ErrorCheckStubData ="%(Midl.ErrorCheckStubData)"
ExcludedInputPaths ="$(ExcludePath)"
GenerateClientFiles ="%(Midl.GenerateClientFiles)"
GenerateServerFiles ="%(Midl.GenerateServerFiles)"
GenerateStublessProxies ="%(Midl.GenerateStublessProxies)"
GenerateTypeLibrary ="%(Midl.GenerateTypeLibrary)"
HeaderFileName ="%(Midl.HeaderFileName)"
IgnoreStandardIncludePath ="%(Midl.IgnoreStandardIncludePath)"
InterfaceIdentifierFileName ="%(Midl.InterfaceIdentifierFileName)"
LocaleID ="%(Midl.LocaleID)"
MkTypLibCompatible ="%(Midl.MkTypLibCompatible)"
OutputDirectory ="%(Midl.OutputDirectory)"
PreprocessorDefinitions ="%(Midl.PreprocessorDefinitions)"
ProxyFileName ="%(Midl.ProxyFileName)"
RedirectOutputAndErrors ="%(Midl.RedirectOutputAndErrors)"
ServerStubFile ="%(Midl.ServerStubFile)"
StructMemberAlignment ="%(Midl.StructMemberAlignment)"
SuppressCompilerWarnings ="%(Midl.SuppressCompilerWarnings)"
SuppressStartupBanner ="%(Midl.SuppressStartupBanner)"
TargetEnvironment ="%(Midl.TargetEnvironment)"
TypeLibFormat ="%(Midl.TypeLibFormat)"
TypeLibraryName ="%(Midl.TypeLibraryName)"
UndefinePreprocessorDefinitions ="%(Midl.UndefinePreprocessorDefinitions)"
ValidateAllParameters ="%(Midl.ValidateAllParameters)"
WarnAsError ="%(Midl.WarnAsError)"
WarningLevel ="%(Midl.WarningLevel)"
TrackerLogDirectory ="%(Midl.TrackerLogDirectory)"
MinimalRebuildFromTracking ="%(Midl.MinimalRebuildFromTracking)"
ToolArchitecture ="$(MidlToolArchitecture)"
TrackerFrameworkPath ="$(MidlTrackerFrameworkPath)"
TrackerSdkPath ="$(MidlTrackerSdkPath)"
TLogReadFiles ="#(MIDLTLogReadFiles)"
TLogWriteFiles ="#(MIDLTLogWriteFiles)"
ToolExe ="$(MIDLToolExe)"
ToolPath ="$(MIDLToolPath)"
TrackFileAccess ="$(TrackFileAccess)"
AcceptableNonZeroExitCodes ="%(Midl.AcceptableNonZeroExitCodes)"
YieldDuringToolExecution ="$(MidlYieldDuringToolExecution)"
>
</MIDL>
Can somebody please tell me whats going wrong here. This is driving me crazy!!!!!!
Got a similar error today on a project that I am converting to VS2010. I don't have a good solution to the problem yet, but I have a workaround. In my case, the project contained 2 idl files. Call them A.idl and B.idl. A.idl is the main idl for the project. It includes B.Idl. The error I received was:
error MSB4094: "A.idl;B.idl" is an invalid value for the "Source" parameter of the "MIDL" task. Multiple items cannot be passed into a parameter of type "Microsoft.Build.Framework.ITaskItem".
It seems that the build system searched for all idl files in the project and made a single call to the MIDL compiler with all of them even though that was bound to fail. I don't know why VS2010 does that and earlier version didn't (or maybe earlier versions of MIDL could handle multiple inputs).
The workaround: grab the MIDL arguments off of MIDL Command Line page of the project's properties. Then run MIDL by hand in a VS2010 Command Prompt window using those args. In my case, since A.idl includes B.idl, I only needed to run one MIDL command:
MIDL options-copied-from-project-properties A.IDL
It looks like you have multiple idl files in your project (hdxBinding.idl, hdxBlinking.idl, etc.). So the same trick might work for you.
Good luck
I ran into this issue trying to build the DataMonitor example from the TMG SDK with Visual Studio 2010. The problem from what I can tell is the MIDL > Output settings in the project - the Header File, IID File, Proxy File, and Type Library were set to "DataMonitor...", which was forcing those settings to be applied to all included IDL files (and not just the project's generated one).
Changing those settings to use %(Filename) instead and the project built fine.
When there are multiple IDL files in the project I converted from VS 2008 to VS 2010, I got this error. Since one IDL I had was included in the other. I disabled building of the included IDL file and it resolved this error.
These errors prop up when migrating to VS2010 as the .idl file properties are not migrated by VS2010 migrator. I got a similar error and resolved this by manually adding these parameters from to VS2010. Once done you will be able to get rid of these build errors.
I run into the same problem as well. The fix was (very confusing) remove empty in the vcxproj file. I run out of time and have not got to the bottom of why it helps - defining not empty HeaderFileName fixes the problem as well, other empty elements do not cause this problem (e.g. DllDataFileName).
If you want to reproduce bug or process of my investigation just create hello world and add two idl files. It should work. However if you add ItemGroupDefinition with Midl.HeaderFileName it should start failing. One wild guess is that it has something to do with batching of tasks (working example calls MIDL task for each file separately).
I'm using ant.bat (in Ant 1.7.1) to build the all target in a build.xml file, on Windows 2003 Server. (I've substituted "xxx" in the error message for the project name in that file.)
It builds successfully, but then ends with:
2009-06-10 17:26:03 | all:
2009-06-10 17:26:03 |
2009-06-10 17:26:03 | BUILD FAILED
2009-06-10 17:26:03 | Target "1" does not exist in the project "xxx".
...and returns with a non-zero error code.
I've searched build.xml unsuccessfully for anything that might lead to this error. (There is no target "1", of course, nor any dependencies that might resolve "1".)
I'm hoping someone out there might recall seeing this. I don't expect anyone to debug the XML for me, but a Google search turned up http://simile.mit.edu/mail/ReadMsg?listId=9&msgId=2735, which contains "I found an email thread on this problem and will
retry.". I wish I could find that thread.
Update - here's the command-line:
D:/build/toolchain/noarch/ant-1.7.1/bin/ant.bat all -DBRANCH_NAME="main" -DBUILD_NUMBER="66675" -DCHANGE_NUMBER="1061789" -DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1 -DGOBUILD_VICLIB_ROOT=d:/build/ob/bora-66675/compcache//viclib/ob-65655/windows -DGOBUILD_VIMBASE_ROOT=d:/build/ob/bora-66675/compcache//vimbase/ob-64494/windows -DOBJDIR="beta" -DPRODUCT_BUILD_NUMBER="82" -DPUBLISH_DIR="d:/build/ob/bora-66675/publish" -DRELTYPE="beta" -DREMOTE_COPY_SCRIPT="D:/build/toolchain/win32/python-2.5/python.exe D:/build/gobuild/script/gobuildc.py bora-66675"'
Hopefully it's of some help.
Do you have any targets that depend on "1"? Perhaps due to a typo?
<target name="SomeTarget" depends="1">
....
</target>
Update: You explained (paraphrased) that the error message was a result of the (partial) command-line
-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1
Although there's a space between those two define statements, it's being treated like this:
-DGOBUILD_AUTO_COMPONENTS=-DGOBUILD_OFFICIAL_BUILD=1
because something is expected to follow '='. And it appears that the second '=' is being treated as a whitespace, perhaps because ANT is confused. I would not expect that. The correct way to do what you want to do is:
-DGOBUILD_AUTO_COMPONENTS="" -DGOBUILD_OFFICIAL_BUILD=1
That way, something follows the equals sign and ANT won't get confused.
could you add the commandline you are using. it could be that ant agrees with you that there is no target '1' but that it believes you are passing one in.
This posting helped me resolve this error and wanted to share my version of the problem.
Target "listener" does not exist in the project "null".
ANT will use an environment variable ANT_ARGS if it is set. I was using the -listener option and set this option in my Windows envvar, ANT_ARGS. When I pasted the options into the Env Var:
-listener org.apache.tools.ant.listener.Log4jListener -lib D:\apache-ant-1.7.1\lib
I was missing the 'minus' sign in front of the 'listener' option.
This is similar to the problem above, but was hidden by the fact that I used the envvar ANT_ARGS.
Ya goose :-) You changed the project to "xxx" in the heading but left it as "vireporting" in the error output.
So the cat's out of the bag. You may as well make our life easier and post the XML since our ability to help you (psychic debugging) is greatly limited. If you want, sanitize the XML you post (better than you sanitized the original, hopefully).
And your comment ('There is no target "1"') makes sense since that's what ant is telling you. What you may have done is inadvertently created a dependency on that non-existent target.
It turns out this error message is the result of "-DGOBUILD_AUTO_COMPONENTS= -DGOBUILD_OFFICIAL_BUILD=1" in the command-line. I guess having nothing after the '=' in that -D option confuses Ant. (As an experiment, I changed "-DGOBUILD_OFFICIAL_BUILD=1" to "-DGOBUILD_OFFICIAL_BUILD=2" in this programmatically-generated command-line and the error message changed to "Target "2" does not exist in the project "xxx".")
Removing "-DGOBUILD_AUTO_COMPONENTS=" eliminated the build failure.
If someone can clearly explain why Ant emits such a strange error message in this case (or perhaps why it's not strange if one looks at it correctly), I'll accept your answer.