I want use Intellilock 1.8 for locking a Outlook2010 Add-in package.
It includes among other Mocrosoft VSTO dlls my custom signed dll and the manifest file with security hash.
I provided project *.snk Key File when locking that dll but still receive an error when try to install the final package:
System.Deployment.Application.InvalidDeploymentException: File,
OutlookAddIn2010.dll, has a different computed hash than specified in
manifest.
The original Visual Studio Setup also automatically creates signed ClickOnce manifest.
The main dll is mentioned in this section:
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="OutlookAddIn2010.dll" size="275968">
<assemblyIdentity name="OutlookAddIn2010" version="2.7.0.0" publicKeyToken="DEDC24E24E6D7D88" language="neutral" processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<dsig:DigestValue>Vg17KBReMnOV9emW0ddVuN7AaIU=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
The solution is to apply IntelliLock signing before the main build.
The solution is the same as in this question.
<Target Name="AfterCompile">
<Exec Command="$(IntelliLockLocation) -project $(IntelliLockProject) -file "$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" -targetfile "$(ProjectDir)$(IntermediateOutputPath)$(TargetFileName)" -snkeypair "$(ProjectDir)$(AssemblyOriginatorKeyFile)" -snpassword *****" />
</Target>
Related
Visual Studio 2019, .Net Standard 2.0
How do I include a custom msbuild targets file for the consuming project?
What is the official supported way of doing this?
I've already tried:
modifying the csproj file as per (Setting Nuget package target path for item in MSBuild project)
trying to specify a nuspec file as per (https://natemcmaster.com/blog/2017/11/11/build-tools-in-nuget/)
Nuspec:
<?xml version="1.0"?>
<package >
<metadata>
<id>TestingNugetContent</id>
<version>1.0.10</version>
<title>Blah</title>
<authors>Me</authors>
<owners>Me</owners>
<licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
<projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
<iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Blah</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright>Copyright 2019</copyright>
<tags>Tag1 Tag2</tags>
</metadata>
<files>
<file src="Immutable\*.*" target="content/Immutable/" />
<file src="Build\*.*" target="build/netstandard2.0/" />
</files>
</package>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0</TargetFrameworks>
</PropertyGroup>
<PropertyGroup>
<NoPackageAnalysis>true</NoPackageAnalysis>
<NuspecFile>TestingNugetContent.nuspec</NuspecFile>
<IntermediatePackDir>$(MSBuildProjectDirectory)/bin/$(Configuration)/publish/</IntermediatePackDir>
<PublishDir>$(IntermediatePackDir)$(TargetFramework)/</PublishDir>
<NuspecProperties>publishDir=$([MSBuild]::NormalizeDirectory($(IntermediatePackDir)))</NuspecProperties>
<Version>1.0.10</Version>
</PropertyGroup>
<ItemGroup>
<Compile Remove="build\**" />
<EmbeddedResource Remove="build\**" />
<None Remove="build\**" />
</ItemGroup>
<ItemGroup>
<None Include="build\netstandard2.0\TestingNugetContent.targets" />
</ItemGroup>
<Target Name="PublishAll" BeforeTargets="GenerateNuspec">
<ItemGroup>
<_TargetFramework Include="$(TargetFrameworks)" />
</ItemGroup>
<MSBuild Projects="$(MSBuildProjectFullPath)" Targets="Publish" Properties="TargetFramework=%(_TargetFramework.Identity)" />
</Target>
</Project>
Checking the consumer's <***>.csproj.nuget.g.targets file the import project tag for this custom target is missing after installing the Nuget package
As per the docs, the props and targets file names must match the package id exactly. Your nuspec lists the <id> as TestingNugetContent, so the files must be TestingNugetContent.props and TestingNugetContent.targets. They should be either directly in the build/ folder in the package, or the build/<tfm>/ folder (I prefer to be more explicit, so I appriciate you used the netstandard2.0 TFM). Now, your csproj appears to specify a build\netstandard2.0\TestingNugetContent.targets, which looks correct, so I can only guess that it wasn't packed into the correct location somehow.
I don't currently have time to show an example on how to pack it, but you can inspect the contents of your nupkg using NuGet package explorer, or just opening it up as a zip file, see what's "wrong", then adjust your project and try again.
FYI, you shouldn't need to use a nuspec at all, you can use the MSBuild PackagePath metadata on items to specify where MSBuild items are packed. It's unclear to me what the purpose of your PublishAll target is supposed to be. If you added it as part of trying to get your targets file included, you can remove it.
In my Asp.Net MVC 4 project, I've set in the .csproj file to build the view <MvcBuildViews>true</MvcBuildViews>. The problem is that building the project I got the error:
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
I tried to delete the obj folder but the error keep raising. The error specify that the problem is in the authentication tag row:
<system.web>
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" timeout="2880" />
</authentication>
Often, I'm able to run the application by running the application (I got the error), building the app and after that running again.
Doing what #matrixugly suggests will fix the issue, but will also cause the compile-time view checking to stop working as well. I am assuming you still want to error check your views at compile time? If that is the case, better fixes below.
In order to understand why these solutions work, we have to first know how the problem is created:
The developer wants compile-time checking on views, so they set MvcBuildViews=true.
The application builds fine, UNTIL they publish the project.
Subsequent attempts to build the project result in a compile-time error: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
So what causes this issue? When the project is published the compiler, by default it uses <project-dir>\obj\ to place copies of the source files that it will work with. Unfortunately, these files are not automatically deleted when publishing is complete. The next time the developer compiles the project with MvcBuildViews=true, it will error out because the aspnet compiler includes the obj\ folder during compilation, since it is underneath the <project-dir> folder.
So how do we fix this? Well, you have four options:
Set MvcBuildViews=false. I don't really consider this a solution, so let's move on.
Delete the files in <project-dir>\obj\. Works, but can be a hassle since it has to be done after every publish.
Change the path that publishing uses as an intermediate directory through the use of the <BaseIntermediateOutputPath> property in your project config file.Example (Ref: this link):
<BaseIntermediateOutputPath>
[SomeKnownLocationIHaveAccessTo]
</BaseIntermediateOutputPath>
Add a new section in your project config file that deletes the offending files for you on build (reference Microsoft Connect). I've even made it easy for you, just copy and paste:
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\Package\**\*" />
<_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TransformWebConfig\**\*" />
<_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\CSAutoParameterize\**\*" />
<_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\TempPE\**\*" />
</ItemGroup>
<Delete Files="#(_TempWebConfigToDelete)"/>
</Target>
My recommendation would be to use either option 3 or 4.
N.B. For those that have never edited their project file, you can't edit it while loaded. It must first be unloaded by right clicking it and selecting Unload Project. You can then right-click the project and edit the project file. Alternatively, you can edit the file outside of Visual Studio.
I had the exact same problem when trying to publish my web application after enabling MvcBuildViews to validate my Razor syntax
I found this code in my web config
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
Try commenting it out, so that the compiler behavior is not changed
<!--<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>-->
#newmanth answer is excellent, but outdated. Year 2022 and let me tell you - this CleanupForBuildMvcViews is actually oficially included within C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VisualStudio\v16.0\Web\Microsoft.Web.Publishing.targets! :)
It even features the link to (now broken) Microsoft Connect as #newmanth references.
Here is the snippet:
<!--Deal with http://connect.microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="#(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="#(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
However I still get the said exception. In my Case I had to delete AspnetCompileMerge folder too. And name Target in another name, not to overwrite it:
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews2" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_TempWebConfigToDelete Include="$(BaseIntermediateOutputPath)**\AspnetCompileMerge\**\*" />
</ItemGroup>
<Delete Files="#(_TempWebConfigToDelete)"/>
</Target>
I have a wsdl and I'd like to generate jax-ws type Java source from it using IBM Websphere version of wsimport. How can I do this in an easy way? wsimport.bat references com.ibm.ws.jaxws.tools.WsImport to do the code generation.
I solved the problem by calling wsimport directly. Just make sure websphereHome is set to the websphere home folder on your machine. Then genDir is the folder where you want the files to be generated to. Finally, wsdlFile is the path to the wsdl used for generation.
task generateWSDL2Java(type:Exec) {
doFirst{
genDir.mkdirs()
}
cmd = websphereHome + '/bin/wsimport.bat -keep -d '+genDir+' '+wsdlFile
commandLine = ['cmd', '/K', cmd]
}
Here's a simple Ant script, using a WebSphere 6.1 runtime (with the WebSphere Feature Pack, which is required for JAX-WS), which I just tested:
<?xml version="1.0" encoding="UTF-8"?>
<project name="JAX-WS Client">
<property name="was.dir" value="C:\Program Files (x86)\IBM\WebSphere\AppServer"/>
<path id="jaxws.gen.classpath">
<fileset dir="${was.dir}/plugins">
<include name="*com.ibm.wsfp.main_6.1.0.jar" />
<include name="*org.apache.axis2_6.1.0.jar" />
<include name="*com.ibm.jaxws.tools_6.1.0.jar" />
<include name="*com.ibm.jaxb.tools_6.1.0.jar" />
</fileset>
<fileset file="${was.dir}/lib/j2ee.jar"/>
</path>
<!-- Ant task definition for wsimport -->
<taskdef classpathref="jaxws.gen.classpath" name="wsimport" classname="com.sun.tools.ws.ant.WsImport"/>
<target name="wsimport">
<wsimport sourcedestdir="./src" destdir="./build" debug="true" verbose="true"
keep="true" wsdl="${wsdlFile}" />
</target>
</project>
If you have RAD 8, here's the InfoCenter article which describes using the JAX-WS Ant tasks from within that. I'm not sure how other WebSphere development environments compare.
JAX-WS artifacts are portable, which means that you are not required to use IBM's tools. BTW, I think that the wsgen and wsimport tools shipped with WAS actually use code from the Sun/Oracle reference implementation.
Therefore you could use any documented solution for Gradle, even if it is not WebSphere specific.
I'm creating a custom package that needs to modify the web.config file of the destination application, but my config changes never appear in the destination app after installation.
Here's my web.config.transform file:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="AppInstalled" value="false"/>
</appSettings>
</configuration>
This key in the appSettings section is never applied.
Here's my nuspec file:
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>$id$</id>
<version>$version$</version>
<authors>$author$</authors>
<owners>$author$</owners>
<licenseUrl>http://mvcapp.codeplex.com/license</licenseUrl>
<projectUrl>http://mvcapp.codeplex.com/</projectUrl>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>$description$</description>
<tags>mvc app</tags>
</metadata>
<files>
<file src="\bin\Release\MvcApp.MVC3.dll" target="lib" />
<file src="NuGet\Content\ajax-loader.gif" target="Content" />
<file src="NuGet\Content\web.config.transform" target="web.config" />
<file src="NuGet\Views\Install\Index.aspx" target="Views\Install\Index.aspx" />
</files>
</package>
Here's the command I run to package the project from the VS 2010 command prompt:
nuget pack mvcapp.csproj
Any Ideas?
Thanks.
The web.config.transform file needs to go into the content folder:
<file src="NuGet\Content\web.config.transform" target="content" />
I know this is an old question, but it's one of the top google results when searching for why a web.config.transform won't apply, so I hope I'm not out of place applying this here.
TLDR; - clear your nuget files from the target project's packages directory (or I assume up the version number) between iterations of testing.
Full Version;
I had this problem as well. I could see using NuGet Package explorer that my project was packaged appropriately. I had my web.config.transform under "content", and my libs under their respective lib folders. The dll's were getting deployed, the web.config.transform wasn't getting applied.
The destination project I was testing with was under source control, so I'd add the nuget package, see what happened, then rollback the whole directory. However I didn't notice that the packages folder wasn't under source control, so the folders from my initial package install were in there. I wasn't upping the version number in the package nuspec, either, because I didn't think I had to.
Ultimately I ended up having to clear my nuget package's directory from the project's packages directory, forcing the next nuget install attempt to recreate them.
I am using Ivy to publish a snapshot of a built Jar to a locally hosted Nexus repository using the following Ant target.
<target name="publish">
<ivy:publish resolver="nexus_snapshot" pubrevision="SNAPSHOT" overwrite="true">
<artifacts pattern="${dist.dir}/[artifact].[ext]" />
</ivy:publish>
</target>
This appears to work fine, resulting in the Jar and its associated ivy.xml being present in the repository (with filenames mymodule-SNAPSHOT.jar and ivy-SNAPSHOT.jar).
Later, in another build script, I wish to retrieve the Jar and its associated dependencies (i.e. as specified in its ivy.xml) into a directory.
This is the Ant target I'm using.
<target name="deploy">
<delete dir="deploy" />
<mkdir dir="deploy" />
<ivy:settings file="${ivy.dir}/ivy_deploy_settings.xml" />
<ivy:retrieve organisation="myorg" module="mymodule"
inline="true" revision="SNAPSHOT" pattern="deploy/[artifact].[ext]"/>
</target>
This retrieves the Jar to the directory, but not its dependencies. Also, if I add
conf="impl"
to the retrieve, it fails as the configuration is not found.
As such, it seems that the retrieve is simply not referencing the ivy.xml and hence not resolving the dependencies.
Should this work or am I misunderstanding something?
I have now resolved this problem. I believe the issue is simply that Nexus works using POM files rather than Ivy files (by default at least - I can't see any relevant configuration options).
The solution is therefore to generate a suitable POM and publish this along with the Jar.
<target name="publish">
<property name="generated.ivy.file" value="${dist.dir}/ivy.xml" />
<ivy:deliver deliverpattern="${generated.ivy.file}"
organisation="${ivy.organisation}"
module="${ivy.module}" status="integration"
revision="${ivy.revision}"
pubrevision="SNAPSHOT"
conf="impl" />
<ivy:makepom ivyfile="${generated.ivy.file}"
pomfile="${dist.dir}/${ivy.module}.pom"/>
<ivy:publish resolver="nexus_snapshot" pubrevision="SNAPSHOT"
publishivy="false" status="integration" overwrite="true">
<artifacts pattern="${dist.dir}/[artifact].[ext]" />
<artifact name="${ivy.module}" type="pom" ext="pom"/>
</ivy:publish>
</target>
Note that I first generate an Ivy file for the current module (and my desired configuration) to create the POM from.