We Keep Coding

Xamarin processor architecture build error

I updated my VS 2015 recently with the latest patch version and since then I get this error:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
Output:
Restoring NuGet packages...
To prevent NuGet from restoring packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages during build.'
1>------ Rebuild All started: Project: MoneyFox.Shared, Configuration: Debug Any CPU ------
1>C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj(333,3): warning MSB4011: "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\packages\Fody.1.29.4\build\portable-net+sl+win+wpa+wp\Fody.targets" cannot be imported again. It was already imported at "C:\Users\nino\Documents\GitHub\MoneyFox.Windows\Src\MoneyFox.Shared\MoneyFox.Shared.csproj (325,3)". This is most likely a build authoring error. This subsequent import will be ignored.
1>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1820,5): error MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\\mscorlib.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The only other entry is a warning who should be the reason.
Strange is, that the project who the error occurs doesn't have the mscorlib referenced.
The error occurs in the PCL Shared Library part who is referenced by the platform specific projects. Therefore these can't build aswell.
My current build configuration is as follows:
The shared project in special:
Repository: https://github.com/NPadrutt/MoneyFox.Windows/tree/AndroidBackgroundService
I tried to repair vs but that didn't change something, as does reinstall it completly.
Funny is, that I can build it on a windows 7 pc (but get runtime error instead).
Also I can't build my master branch anymore who was buildable some days ago.
What's wrong here!?
EDIT: I created a new portable class library and unloaded all other projects.. I get the same error, also when I create a new project with just a portable class library in it. So it seems there is something pretty wrong with my current installation...

I found a solution for the problem. It seems that some of the .net profile got corrupt. But they didn't get repaired with a reinstall or repair of VS. So, therefore I deleted the Files and folders under the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable
Then I repaired VS and it worked again..

I wouldn't think that this has to do with applying the latest patch to Visual Studio 2015.
We see this warning when we have one project that is built for x86 referencing another build for AnyCPU. This can be fixed in the Project Property page (right-click the project and click Properties). In the Build tap you can set Platform target. I would suggest that you set the configuration combo box in the top of the property window to All configurations before updating this to get it set consistently.
You can also correct this by unloading the project and editing it manually. Look for the AnyCPU property and insure that it is set in a property group without conditions or in all property groups for each configuration condition.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Debug\</OutputPath>
...
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<OutputPath>bin\Release\</OutputPath>
...
</PropertyGroup>

Publish Configuration disabled for csproj

Why can't I change these settings shown in the image below?
This is a clickOnce application, and my problem is that I want to change by publish path, assembly name, product name, install URL, and preform some app.config translations based on the build configuration. I am able to achieve this by manually editing the csproj like so
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<AssemblyName>someApplicationTest</AssemblyName>
<ProductName>Some Application Test</ProductName>
<PublishUrl>c:\publish\someApplicationTest\</PublishUrl>
<InstallUrl>http://sub.example.com/someApplicationTest/</InstallUrl>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<AssemblyName>someApplication</AssemblyName>
<ProductName>Some Application</ProductName>
<PublishUrl>c:\publish\someApplication\</PublishUrl>
<InstallUrl>http://sub.example.com/someApplication/</InstallUrl>
</PropertyGroup>
I'm just confused why these options are disabled in visual studio and if I'm missing something. Perhaps I'm confused and these controls weren't even intended for this purpose.
Also, I'm going to be investigating Squirrel.Windows as an alternative later, but for now I wanted to learn more about this.

This is just a visual representation of the structure of a project file. Some settings can have different values for different configurations. Others have only one value that doesn't depend on the configuration. The best example of the first set are the settings in the Build tab. Of course you want to build your program differently in the Release build. So the configuration combos are enabled.
Also have a look-see in the .csproj file with a text editor, Notepad will do just fine. Note the <PropertyGroup> elements, some have a Condition attribute that enables them for a specific configuration. The publish properties are located in the PropertyGroup without a Condition.
So for the settings in the Publish tab Microsoft decided that it was not necessary to make the settings specific to a configuration. Which makes sense if you think about it, you'd only publish your Release build. Well, normally. So the combos are disabled. Feature, not a bug.

In TFSBuild.Proj file how to <ConfigureToBuild> for Both AnyCPU and x86 Platform?

I have one MyProject.sln project.
In that there is two Class Library Project and one Window Service Project.
Compiler build Class Library Projects on Any CPU Platform and Window Service project Build on X86 platform.
How i will set the so that My Build execute according to selected Platform which i set in project "MyProjectClass.csproj" file
This is Code of TFSBuild.Proj file
<SolutionToBuild Condition="'$(BuildMyProject)'=='True'"
Include="$(SolutionRoot)/MyProject/MyProject.sln">
<Targets>Build</Targets>
<Properties></Properties>
</SolutionToBuild>
Code for
$BuildFlavor = 'Release'
<ConfigurationToBuild Include="$(BuildFlavor)|Any CPU">
<FlavorToBuild>$(BuildFlavor)</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
<ConfigurationToBuild Include="$(BuildFlavor)|x86">
<FlavorToBuild>$(BuildFlavor)</FlavorToBuild>
<PlatformToBuild>x86</PlatformToBuild>
</ConfigurationToBuild>
MSBuild try to build my MyProject.sln for both the platform. it's take more time for build.
It's show that Build Run successfully but not generate the Binaries of Windows Service in specified $DropLocation.
But,
When I was changed my Windows Service project Build Platform from x86 to Any CPU.Now it's working properly.All three project Binaries generated and i got it in my $DropLocation But
[1] Is there any another way to solve this query?
[2] Is TFSBuild execute only one platform for MSBuild compilation?
[3] Is it required that all the platform of subprojects are same for one .sln project?

Modify your solution this way and change your ConfigurationToBuild to:
<ConfigurationToBuild Include="$(BuildFlavor)|Mixed Platforms">
<FlavorToBuild>$(BuildFlavor)</FlavorToBuild>
<PlatformToBuild>Mixed Platforms</PlatformToBuild>
</ConfigurationToBuild>
If you don't have rights to change solution file try following ideas:
Building specific projects from solution with specific target
Try AdditionalProperties Metadata
Build *.csproj files instead of solution file
Build your projects using MSBuild tasks (override Build target)

I had a similar issue - TFSBuild was set up in a way that it picked always the Debug configuration and I didn't have the permissions to change the build definition. I wanted to have the Release configuration to be created in the TFS build.
My solution was to edit the *.csproj files.
The prerequisite for this to work is that the Configuration field is empty in the related TFS build definition's build process parameters (Process / Items to build / Configurations to build). If you have the rights to modify it, you can directly select the desired configuration, save the build definition and skip the steps of the workaround below.
Steps for workaround (right-click on project):
Unload project
Edit project
Now you can edit the project file. Locate
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
and change it to
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
Finally, right click on the project again and select:
Load project
Now queue a new build and it should create it from Release. Likewise, you can enter any other configuration you like, for example you can create Release_TFS in Visual Studio and then insert it instead of Release. This will ensure you have created a separate definition for the TFSBuild before you do that.

How do I fix a corrupted build manager in vs2010?

I have a C# project in vs2010 that has several build options (Debug, Release, Debug x86, Debug I Just Got A New Hat, etc), because some people have gone a bit overboard in adding projects.
I want to revert all of that to just the four basic build types:
debug x86
release x86
debug x64
release x64
I remove a project, save the sln with that project apparently no longer in the solution, and then add it back, but apparently the settings for the project have been saved. Is there any way to remove these extraneous projects entirely from the build manager and start from scratch short of creating a new SLN file?
The impetus for fixing this problem is that one of the projects in the solution won't allow for an x64 build to be made. If I try to create an x64 build for that project, the build manager states that the x64 build already exists, even when though clearly does not. The build manager isn't allowing me to remove build modes, just add them, but then it doesn't let me add the x64, which is what I'm needing.

Quickest way is to manually edit the .proj files in notepad, removing all the
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'NewHat|x64' ">...</PropertyGroup>
elements for each configuration. Then finally remove the unwanted solution configurations by again editing the .sln file in notepad. They are easy to spot.
Once removed, you should be able to open up the solution in VS and set things right in the configuration manager
The alternatives are to use a macro or VS EnvDTE classes to automate the process but that's perhaps the sledgehammer for a nut.

Normally I don't recommend doing this but you may need to take Notepad or your favourite XML editor and change the contents of your csproj file. The reason I don't like to recommend this approach is that if you get the editing wrong you can end up with a broken project.
Obviously you should back everything up before you start so you can at least get back to your current state if everything goes pear shaped.
Ideally you can dig into your Source Code Control system and get a copy of the csproj file from back when it wasn't broken and use that as a rough guide to what a well formed csproj file for your project looks like.
You can also create a completely new C# project using the same template as your project and use that project's csproj file as another guide to what things should look like.
If you're lucky your csproj file will contain a number of PropertyGroup items, some of which will have a condition identifying the particular build combination the group applies to. For example...
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
<OutputPath>bin\x64\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
If you delete the groups for configurations you no longer want and delete any that seem to apply to x64 you may find that the build manager will let you add an x64 configuration.

How do I deploy two ClickOnce versions simultaneously?

I would like the ability to have a test ClickOnce server for my applications where users can run both the production version and the test version in parallel. Is this possible?
I first tried using the following in AssemblyInfo.cs and also changing the name in the ClickOnce deployment though all this achieved was overwriting the users' production version with the test version. Likewise, it did the same when they went back to the production server.
#if DEBUG
[assembly: AssemblyTitle("Product Name - Test")]
#else
[assembly: AssemblyTitle("Product Name")]
#endif
I thought I should also clarify that the two deployment locations are different from one another and on different servers.
UPDATE
I've also tried setting the GUID for the manifest depending on the debug mode, but again it does not work (dummy GUID's used below).
#if DEBUG
[assembly: Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")]
#else
[assembly: Guid("BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB")]
#endif
How are the two distinguished? It seems that the installer sees them as two separate programs as I get a confirmation of installation for each. Though, when I install the second one, "Add/Remove Programs" only sees the latter, though the former is still on disk, as when I go to reinstall it later, it just simply runs, but then the add/remove programs switches back to the former name.

It might sound kind of lame, but the easiest way to do this is to have two EXE projects in your solution. The Main method of each of these will just call the Main method in your original EXE project (which you'll have just switched over to being a DLL file).
This means that each EXE project can have its own ClickOnce publishing settings, as well as its own app.config file. This means you have different connection strings for the production and the test version.
Your other option (the one that might seem to make the most sense) is to use MageUI.exe to manually build the ClickOnce files, which would let you choose a different configuration file and publish location each time you ran the tool. There's also a command line version (Mage.exe) so you could in theory automate this.
However, we found that the solution with two "runner" projects was far far simpler. I'd recommend you try that first.

ClickOnce: Concurrent versions explains how to do this.

I manually edited the .csproj to specify a different ProductName for debug/release.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<PublishUrl>publishbeta\</PublishUrl>
<InstallUrl>http://www.softwareabc.com/download/beta/</InstallUrl>
<ProductName>Software ABC Test</ProductName>
<AssemblyName>SoftABCTest</AssemblyName>
<ApplicationIcon>Resources\Test.ico</ApplicationIcon>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<PublishUrl>publish\</PublishUrl>
<InstallUrl>http://www.softwareabc.com/download/</InstallUrl>
<ProductName>Software ABC</ProductName>
<AssemblyName>SoftABC</AssemblyName>
<ApplicationIcon>Resources\Application.ico</ApplicationIcon>
</PropertyGroup>
One caveat is that Visual Studio 2010 doesn't update this if you switch between debug/release. It only takes effect when it loads the solution so make sure to switch debug/release then close and reopen the solution.

See the succinct video on concurrent versioning: ClickOnce: Concurrent versions.

Try changing the Assembly Name in the Application tab in the properties window.

I do that all the time. I even have a screen in my application that changes which version a specific user will get. And I'm not doing anything tricky on the app side, all the magic is on the web server hosting the ClickOnce files.
Take a look at the article my buddy wrote, Fine Grained Versioning with ClickOnce . It explains how we did it.

A variation on Peter Mortensen's two project scenario. I wanted dev, customer test, and customer release. In my case I wanted the customer test providing some visual clues that it was test, not live (e.g. 'TEST' in the title and a different visual theme).
I found it simplest to have two solutions as well as two stub projects. Each project in its own directory, with its own stub program.cs, app.config and assemblyinfo.cs.
In the dev/test solution, the debug configuration was for dev, the release config was for customer test. I used SlowCheetah to transform the app.config for the latter.
In the customer release solution I needed only a release config.

You have to edit your csproj manually, after having at least once configured your project to publish a Click Once application.
Move some of Click Once related properties from the <PropertyGroup> to the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> property group and duplicate them under the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> property group.
The properties to duplicate are ApplicationRevision (only if you want separate revision counters), PublishUrl, ProductName and SuiteName (the last two are required to be able to differentiate the configurations on the target machines). You also will have to override the AssemblyName property (without removing it from the first group).
If you want to be able to debug your project under any configuration, you also will have to add the StartAction and StartProgram properties in each group where you overrode the AssemblyName property.
After having given these properties adequate (i.e. different) values, you will be able to publish both configurations, without having to modify your project, just by selecting the desired configuration. Note however you will have to unload your project between publishes for different configurations, or Visual Studio will mess up your parameters.
After that, you also will be able to install both versions on the same target machine.

It is possible to deploy 2 versions of the same application without changing the AssemblyName, here is how it's done...
Create a clickonce deployment
Open the .application file and make the following edit:
3. Run the setup and MyApp will be installed. Depending on previous attempts you may need to clear the application cache with mage -cc
Edit the .application file again replacing MyApp with MyApp2
Run setup and MyApp2 will be installed