I'm working on a ClickOnce app that's set to online-only. I publish it to an internal IIS server, with an HTML page in the same directory that contains this link:
The deployment looks like so, with all files except the HTML page generated by my project's publish target:
MyAppName
-> Application Files
-> MyAppName_2213_20_0_65
-> <The published files>
-> default.html
-> MyAppName.application
When I click the link, the app runs immediately without any confirmation prompt, and I see from the about box that it's the old version. When I browse to the file share and launch MyAppName.application by double-clicking on it in Explorer, I get the prompt asking me if I'd like to run it, and then it downloads and I get an error:
Unable to install this application because an application with the same identity is already installed. To install this application, either modify the manifest version for this application or uninstall the preexisting application.
As part of the build process, I set the InstallUrl property of the project to http://ourserver/MyAppName/MyAppName.application. Is that wrong? Should it be the HTML page that contains the link? How is it determining the "identity" that's generating a conflict?
Since the app's online-only, it's not installed and doesn't show up in the Programs and Features control panel (and therefore that part of the error message doesn't apply).
I'm new to ClickOnce, so let me know if I left out some helpful information.
Update
If I run mage -cc from a Visual Studio command prompt, the new version launches instead of the old one.
Update 2
As I poked around more, I'm seeing something that looks wrong, and could be the problem. I see the following two lines in my MyAppName.application file (the deployment manifest):
...
<assemblyIdentity name="MyAppName" version="1.0.0.0" ...
...
<dependency>
<dependentAssembly dependencyType="install" codebase="Application Files\MyAppName_2213_20_0_65\MyAppName.exe.manifest" size="82044">
<assemblyIdentity name="MyAppName.exe" version="1.0.0.0" ...
...
You can see the mismatch above. It's deploying to MyAppName_2213_20_0_65, but it thinks the version number of the exe is 1.0.0.0. I'm not sure why it thinks that. My project includes a file that gets generated as part of the build with this line:
[assembly: AssemblyVersion("2213.20.0.65")]
Then, to set the published version number, I have this in my csproj file:
<Target Name="BeforePublish">
<GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
<Output TaskParameter="Assemblies" ItemName="MyAppAssemblyInfo" />
</GetAssemblyIdentity>
<PropertyGroup>
<ApplicationVersion>%(MyAppAssemblyInfo.Version)</ApplicationVersion>
<InstallUrl>$(INSTALL_URL)</InstallUrl>
</PropertyGroup>
</Target>
Does the assembly version listed for my executable even matter? If it does, why is it stuck on 1.0.0.0, and could that be affecting the download of updated versions?
My second update put me on the right track. The problem was indeed the incorrect version number for the assemblyIdentity attributes. To fix it, I'm no longer using a BeforePublish target. Instead, I'm passing in the ApplicationVersion when I call MSBuild:
"%msbuild_path%" MyAppName.csproj /target:Publish /p:ApplicationVersion=%VERSION%
Related
This is pretty easy to replicate but also code here:
https://github.com/dominicshaw/dotnet-publish-error
create an empty wpf project using .NET7
create a publish profile for ClickOnce
publish via command line (not visual studio)
Publish profile is almost totally standard (view here)
Command line from project directory:
dotnet publish PublishError.csproj -p:PublishProfile=ClickOnceProfile
Subsequent error:
MSBuild version 17.4.0+18d5aef85 for .NET
Determining projects to restore...
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100\Microsoft.Common.CurrentVersion.targets(4149,5): error MSB4062: The "Microsoft.Build.Tasks.RequiresFr
amework35SP1Assembly" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKey
Token=b03f5f7f11d50a3a. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, a
nd that the task contains a public class that implements Microsoft.Build.Framework.ITask. [C:\Users\shawd\source\repos\PublishError\Publi
shError\PublishError.csproj]
I have the latest SDKs installed and VS2022 up to date. This only happens via command line - I am able to publish from Visual Studio (I am setting up devops, so require command line).
This happens regardless of adding nuget package for Microsoft.Build.Tasks.Core. Note however nuget package v15.1.0.0 is not available - I have tried 15.1.548 and the latest instead.
Totally at a loss! Any ideas very welcome.
Thanks vm
During the tests with your project and files, I finally managed to publish it successfully with the command dotnet publish PublishError.csproj -p:PublishProfile=FolderProfile.
Here is the document for dotnet publish, as is referred,
The preceding example uses the FolderProfile.pubxml file that is found
in the <project_folder>/Properties/PublishProfiles folder. If you
specify a path and file extension when setting the PublishProfile
property, they are ignored. MSBuild by default looks in the
Properties/PublishProfiles folder and assumes the pubxml file
extension.
And I also succeeded with dotnet publish with your project.
==============================
update on 11/19
So I suppose that the issue is resulted from your definition for -p:PublishProfile=ClickOnceProfile,it will change the path where this command would search for the publish file
A partial answer as my workaround for anyone struggling with a similar problem:
I have found it impossible to do this with the dotnet cli but I can do it with MSBuild if I specifically target 17.4 (VS2022). By default, my Azure DevOps Server 2020 capability is the 2019 MSBuild (15.X), so I have to be explicit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Current\Bin\MSBuild.exe" /restore /Verbosity:m /t:Publish /p:RuntimeIdentifier=win-x64 /p:configuration=Release /p:PublishProfile=ClickOnceProfile
This works - so in my pipeline I have created a batch file which runs this, then I copy the files to my ClickOnce location.
Not ideal, but a working pipeline.
Interesting side note - this dotnet cli command which should be idenitical (and indeed uses the correct 17.4 MSBuild) - does not work (with the same error):
dotnet msbuild -target:Publish -property:RuntimeIdentifiers=win-x64;Configuration=Release;PublishProfile=ClickOnceProfile
I want to change the version of cxf on Service Mix 7.0.1 where cxf version is 3.1.9 . Because of using Brave tracing that is implemented in 3.1.12 version of cxf.
So Is there a way to change the version of the CXF on Service Mix.
I have deleted manually everything in the system/apache/cxf folder that has 3.1.9 version and add a file with 3.2.5 version. But it is still not working. When I write feature:list all of the cxf dependencies are with 3.1.9 version...
Deleting files from the system folder won't work. It does not scan the system folder for files, but rather uses it as a cache to go looking for specific versions. You don't need to add new versions to system either because it will download them from the central maven repo it they arn't in system.
If it starts up without a data folder, it will install features & versions listed in org.apache.karaf.features.cfg
One would expect to be able to delete the data folder, change the version in org.apache.karaf.features.cfg & start it up, but I tried that and Camel was broken. Unsure why.
I find it easier to deal with it using the management console.
Install the management console by dropping the following xml file into the deploy folder:
<features name="features-murray" xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0 http://karaf.apache.org/xmlns/features/v1.2.0">
<repository>mvn:io.hawt/hawtio-karaf/1.5.7/xml/features</repository>
<feature name="murray" version="1" install="auto">
<feature>hawtio-offline</feature>
</feature>
</features>
Then point your browser at http://localhost:8181/hawtio and login with SMX/SMX.
From OSGI/Features add the your new feature version with the plus button:
mvn:org.apache.cxf.karaf/apache-cxf/3.1.12/xml/features
It may take some time to install, because it downloads it from the net. I found it bounced me out of the management console also, but after logging back in I could uninstall the old cxf 3.1.9. It again logged me out of the management console, but after logging back in I had Camel active and CXF on 3.1.12.
No testing though - goodness knows what else is broken.
I'm facing a problem right now and I don't really know how to get more informations about it.
I've converted a desktop application through Microsoft's Desktop App Converter, made some manual modifications about the visual assets, and rebundled it through "makeappx.exe". Then I signed it.
Everything went fine. Except that when I double click the appx to check it, I have the following window:
Appx Error
Which roughly translates as "Couldn't open the appx or appxbundle file" and "Reason: Failure caused by an unknown reason".
This does not helps me a lot :/
However, if I try to install the package through a simple "Add-appxpackage MyPackage.appx", it works perfectly fine.
Could anyone help me find some leads on what's happening here? I've already checked the event viewer as explained here but I couldn't find anything unusual.
Thanks,
Skefrep
It seems the Microsoft team has taken notice of this problem and investigated this appropriately.
-Here is their solution-
The problem can be because when you convert an app with DesktopBridge the resources are signed with the manifest info and store that info in the .pri files you found in PackageFiles folder. Later, when you change something like the Publisher or the Name this signature doesn't match. To fix this you only need to recreate the .pri files.
rm *.pri. Remove the old .pri files.
cd C:\foo\PackageFiles\. Change current directory to the PackageFiles folder. This step is important for the next step.
makepri createconfig /cf priconfig.xml /dq en-US. Create a configuration file for the resources.
makepri new /pr "C:\foo\PackageFiles" /cf "C:\foo\PackageFiles\priconfig.xml". Generate the new *.pri files.
Then you can make the package as usual: MakeAppx, etc.
You can find more information about this problem in "Failed due to unknown reasons" error when you try to sideload a Desktop Bridge app - App Consult Team.
It's a WPF application, with Wix Installer.
I have resourceses folder and I want to include these files in the installer to put next to the executable. I solved generating a resources.wxs file with necessary information about the files under the resources folder using the heat tool. I managed to includ into the main wxs file. For that reason I modified the .wixproj file, adding a before build target action to generate the wxs and include it in the main wxs.
Concern: .wixproj is kind of hidden, there thing that you cannot modify from visual studio, like adding a before build action (pre build action is a different story)
Question: How can I extract the before build action into a separate file?
The before build action in the .wixproj:
<Target Name='BeforeBuild'>
<Exec Command='"%WIX%bin\heat" dir $(SolutionDir)resources -dr ResourcesDir -var var.ResourcesDir -cg ResourceFilesGroup -gg -g1 -sfrag -srd -out $(ProjectDir)Resources.wxs' />
<ItemGroup>
<Compile Include='$(ProjectDir)Resources.wxs' />
</ItemGroup>
You can extract it into a separate file—most project file types do that already. That's how they provide common targets to all projects of a type. A .wixproj has this:
<Import Project="$(WixVersionTargetsPath)" />
To augment your own, simply:
Create an XML file like:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name='BeforeBuild'>
<!-- tasks -->
</Target>
</Project>
Add an Import element inside the Project element and refer to that file:
<Import Project="custom.targets" />
If such a file primarily has Target elements, the convention is for it to have the file extension ".targets".
But there are two drawbacks with Visual Studio:
Visual Studio caches all the project file dependencies and runs the MSBuild internally. So, it you edit the external file, it won't be part of builds using Visual Studio until the project is next loaded. To quickly unload and reload a project, use the project context menu in the Solution Explorer. Workaround: Call MSBuild yourself.
When Visual Studio loads a project, if it includes non-standard external files, it gives a warning. (You can disable it per user by project file path, in the registry, if I recall.)
As an alternative to calling heat directly, you might want to look at the Harvest* targets that WiX provides. Note: As the documentation says, you don't invoke them directly (they're already invoked by the Build target); You simply add items to the ItemGroup they process and set properties they use.
I am unable to build my Web Application (not Web Site) in our build environement. We use DMAKE in our build environment (this unfortunately is non negotiable, therefore using MSBUILD is not permitted ) and when invoking the asp.net precompiler through
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -d -nologo -p Site -f -fixednames -errorstack -v / Debug
We get the following error
error ASPPARSE: Could not load type 'X.Y.Admin.Site.Global
If I compile from the ide it is successful. If i then compile with aspnet_compilier it is successful. So i only get a successful compile with aspnet_compiler when the target dll i am trying to compile is in the bin of the web application i am compiling.
I keep running into postings that talk about solutions using MSBUILD which unfortunately I cant try.
Any help would be appreciated
We had the same problem on our web application:
error ASPPARSE: Could not load type '...'
The problem was that we had the file on disk (on the project folder) but it wasn't included in our application project (in the .csproj file). We solved the problem by including the file in the project :)
I ran into a similar problem using NANT. The trick was to compile the web applications code files into a dll then include that when using aspnet_compiler.
use the command line compiler,either csc.exe (c#) or vbc.exe (visual basic), to compile your web application with an output of type library. This will create a dll that you can use in your aspnet_compiler task
Have you tried specifying the path using -p? Sounds to me like it can't find that type / assembly.
http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx
For web applications, you have to build the .vb files into a dll and put that in the bin folder before you run the aspnet compiler. Check the output window in visual studio and you'll see the command line for the VB compiler. Run that first before you run the aspnet compiler, and the asp pages should be able to find the missing types.
This problem was resolved for me by simply deleting all bin and obj folders. Seems like they were in a bad state somehow. I also deleted the the .sou file, but I don't think that was the issue.
I received the same problem.
I fixed it by copying my webapp's DLL from the OBJ/DEBUG folder to the BIN folder.
I just had this error and found 2 ways to fix it, either:
Change the Codebehind attribute in the global.asax file to CodeFile and add "partial" to the class declaration
In the deployment project's property pages, set "Version output assemblies" and provide a version number
I don't really know why either worked, but it did.
solution :
-p Site path must have the directory path of .csproj file location.
ex :-
aspnet_compiler -p D:\Projects\MGM\mgm\mgm -v / D:\Projects\MGM-deploy\mgm_compiled