Hy,
i have a Xamarin Prism application basically created with the PRISM Template Pack.
My modules are separated dlls.
I want to debug the modules code. So i add the source page in my shell applications visual studio window and set breakpoints.
When i run my application and open Debug-Window-Module dialog, i can see that my module status is "symbols loaded in VM".
So everything looks fine to me.
BUT the debugger doesn´t stop on my breakpoints.
Can anyone tell me what i can do to have debugging?
Thanks
Check out the solution submitted by #Breeze Liu - MSFT for this similar post.
It is possible that you need to edit the .csproj file of the shared project to include the following:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugType>Full</DebugType>
</PropertyGroup>
Related
I have an issue updating my UWP app on Windows store. The issue is on the level of Visual studio (for windows). The description of the issue is the following:
Error info: error 80080204: The package with file name "MyApp_VersionNumber_x64.msix" and package full name "PackageName_VersionNumber_x64__Suffix" is not valid in the bundle because it has a different package family name than other packages in the bundle. The expected publisher is CN=PublisherName. AppName Prefix_Path\AppName\MakeAppx
The context is the following:
I update the app source code, then I associated the app in the store with the one updated.
In the windows related to the Application packages creation:
a. I choosed the distribute the application in windows store
b. Next, I choosed to always generate the application bath. (When I choose not to generate, it is impossible to publish the update because appxbundle is missing)
c. I selected the build x86, x64 and ARM like I did before
d. Finally I launch the creation to get the error above.
I followed multiple possible answer but nothing works.
Can someone helps me to overcome this issue?
Regards.
I had the same problem, the fix is a bit annoying, but for me it worked:
Close Visual Studio, go into your fileexplorer and open up the Folder with your project. Inside it you should find the "projectname.csproj" file. Open it up in your favorite texteditor and now follow the steps below:
1: Look for this line and also make sure it is the line with 'Release' and not 'Debug' in it:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
2: Inside the PropertyGroup tags you will find this line:
The value can either be true or false. If it is false, change it to true
<UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>
Now repeate these steps for all four Release configurations and ONLY Release not Debug:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|ARM'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|ARM64'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
After this, save the file and reopen Visual Studio. It now should create the package.
A developer migrated a csproj file to the newer csproj syntax. The top of the csproj file follows:
<Project DefaultTargets="Build" Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{4CF6CFA6-13B2-426E-913B-A42BF6642A69}</ProjectGuid>
<TargetFrameworks>net472;netcoreapp3.1</TargetFrameworks>
<RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>
Other developers were no longer able to open the two solution files containing this project. Visual studio would begin opening the solution, but the progress bar would hang when it got to this converted project. It should be noted that many other projects had been migrated without this issue.
A blank solution was created and the hanging project was added to this blank solution. This opened without a hang.
Any ideas on what could be done to allow this project to not hang. I suppose a new project could be created as a work around.
I was able to correct the hang by creating a new project GUID and replacing the old project GUID in the csproj and sln files. This allowed the solution to open. I used the Visual Studio GUID tool available in the Visual Studio Tools main menu to create the GUID in registry format.
I'm writing an add-in for Outlook using the new framework. The manifest in the project template uses ~remoteAppUrl to represent the location of the web files. It works great during development, but to publish to the Office Store I need the production URL there. If I save the production URL to the manifest, the production server gets used during debugging, and so local changes don't show up.
The documentation mentions Visual Studio filling in this value during debugging:
Next, Visual Studio does the following:
1. Modifies the SourceLocation element of the XML manifest file by replacing the ~remoteAppUrl token with the fully qualified address of the start page (for example, http://localhost/MyAgave.html).
Is there a built-in way to have Visual Studio fill in the production URL at the appropriate time (before/during Office Store submittal), and not break debugging?
Yes, there is a built-in way to have Visual Studio replace the ~remoteAppUrl symbolic reference token by the target URL of your choice.
From Visual Studio, access the "Publish..." option of the add-in
project, then click on the "Package the add-in" button
You can then enter the URL in the modal dialog that pops up
A build is then triggered that will inject the URL in the produced Manifest XML file
A Windows Explorer window will conveniently open to show the
produced file.
The following ways are not built-in but may be useful as well.
If you want this in an automated build, you need to specify values for the build parameters IsPackaging (True) and RemoteAppUrl.
If you want this in the standard Visual Studio Build, given that Visual Studio does not provide an easy way to specify Build parameters (see How to emulate /p msbuild parameter in Visual Studio build?) you will need to edit your project file to set the values of the same build parameters.
For instance like this:
...
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
...
<IsPackaging>True</IsPackaging>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<RemoteAppUrl>https://localhost:44300</RemoteAppUrl>
</PropertyGroup>
...
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<RemoteAppUrl>https://your.own.url</RemoteAppUrl>
</PropertyGroup>
...
Edit:
Visual Studio will not fill in the production URL, however you can copy your current manifest and replace the ~remoteAppUrl with your appropriate host manually, thus giving you a production and debug version of your add-in.
Original for posterity
~remoteAppUrl is a placeholder for wherever your files are hosted. For instance, if you have uploaded your add-in to an Azure Web App, your remote app url would be something along the lines of myWebApp.azurewebsites.net
I would like to bring the light on where the value comes from to replace the ~remoteAppUrl parameter. Add-in .csproj file contains the reference to the WebApp project:
<ItemGroup>
<ProjectReference Include="..\OutlookWebAddIn1Web\OutlookWebAddIn1Web.csproj">
<Project>{57AC33A8-A364-4084-B41F-319C5DBB9FB4}</Project>
<Name>OutlookWebAddIn1Web</Name>
<Private>True</Private>
<RoleType>Web</RoleType>
<OutputItemType>SharePointWebProjectOutput</OutputItemType>
<RoleName>OutlookWebAddIn1Web</RoleName>
<ReferenceOutputAssembly>False</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
I think it takes the URL from the WebApp .csproj file:
This particular problem is a big one.
In my current configuration Visual Studio 2013 builds my project if it is in Debug configuration, but not if it is in Release configuration.
Somehow when I select Release, 160 errors pup up and when I go through them they are in impossible places. Here is one example.
Visual studios Error is the following:
Error 3 ; expected E:\Users\Robert\Documents\Visual Studio 2013\Projects\GW2.NET\GW2.NET\GW2.NET\V1\MapInformation\DataProvider\ContinentData.cs 96 36 GW2.NET
And here is the code in question:
public static async Task<T> GetContentAsync<T>(string apiMethod, List<KeyValuePair<string, object>> arguments, Categories category)
{
var response = await GetJsonAsync(apiMethod, arguments, category);
return await Task.Factory.StartNew(() => JsonConvert.DeserializeObject<T>(response));
}
You see there isn't any error. If there were one, the Debug configuration wouldn't build either. I already tried to clean the solution and got the latest from TFS, and I deleted and recreated the configurations.
For now I am at my wit's end. How can I fix this?
The project is a C# 4.0 project with the Microsoft async, JSON.NET, and Rest# packages.
If you are really stuck, one thing you could do is open up the .csproj file in a text or XML editor and inspect the actual XML content in there. You're trying to figure out what settings/properties are set differently based on Debug/Release configurations. This might give you some insight into what it is doing different between the two configurations.
OK, if anyone else has the same problem, here is what I did. Thanks to Dylan Smith, I got to the solution.
Open your .csproj file with a text editor of your choice. I used Notepad++, but Visual Studio is also working. At the top there should be elements called PropertyGroup. Those elements define your build configurations. For me there were two:
One for Debug:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
<DocumentationFile>bin\Debug\GW2.NET.XML</DocumentationFile>
</PropertyGroup>
And one for Release:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>none</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<DocumentationFile>bin\Release\GW2.NET.XML</DocumentationFile>
<LangVersion>4</LangVersion>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
Apart from the obvious differences, with the first two nodes (DebugSymbols and DebugType), the main difference was the LangVersion element. I deleted it and voilà the project builds in release mode too.
So if you have the same problem as me, open the .csproj file and delete this node. This should solve it.
P.S.: What does the LangVersion element mean? If I change it from 4 to, say, 4.0, I get the following error:
Invalid option '4.0' for /langversion; must be ISO-1, ISO-2, 3, 4, 5 or Default
If you are building a WiX setup project using Visual Studio 2010 with your own custom dialog boxes and your project builds in debug mode, but not in release mode, then go to menu Project → Properties → set Tool Settings to Release Mode and check the checkbox Suppress ICE validation.
The scenario is: I'm building my solution with TeamCity, I'm not running the build account as an administrator; so I get problems with the strong name keys.
I know of a few solutions out there, like running the build as an administrator and registering the certificates in the proper container.
Is there anyway to sign the assemblies within a solution file only during a release build and not during a debug build. Or are there any similar solutions?
I think it is strange that there isn't a MSBuild parameter that can be set wether the assemblies should be signed or not. Because if you look at the csproj-files there is an option there for signed or not signed
Another option is to edit the project file. By default if you enable assembly signing in Visual Studio it will be used for all build configurations. The project file contains an element like the following.
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>YourKeyFile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
If you only want to sign the assemblies during a specifc build configuration, such as RELEASE. You can put the <SignAssembly> and <AssemblyOriginatorKeyFile> in the PropertyGroup element with the Condition that identifies your build configuration.
So if you want to sign your assembly during a release build, you can change your project file to the following.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<!-- other element of this PropertyGroup -->
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>YourKeyFile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
Note: When you change your project file, to the following. you cannot change the signing settings of the Project Properties in Visual Studio. That means in Visual Studio is signing of the assembly disabled, also if you change the build configuration in Visual Studio.
Here's a solution where the assembly is signed in Release configuration, but not in Debug configuration. It uses the signing facilities from the project, not using the [AssemblyKeyFile] attribute. It's basically the same as Jehof's answer but in other words.
Set up the project for signing in the Signing tab in project preferences.
Unload the project, and edit it in the XML editor. Locate the SignAssembly property. Move that property into the two configuration dependent property groups. In the Debug configuration, set the property to false.
This will look something like this:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<!-- ... -->
<SignAssembly>false</SignAssembly>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<SignAssembly>true</SignAssembly>
</PropertyGroup>
Visual Studio works correctly even when changing build configurations, with the exception of the Sign the assembly check box in the Signing tab. I tested with Visual Studio 2008.
Cave-Eats:
You need to remove the [AssemblyKeyFile] attribute for this to work.
If you have [InternalsVisibleTo] attributes, you need to maintain two versions, like this:
#if DEBUG
[assembly: InternalsVisibleTo("MyLib.NUnit")]
#else
[assembly: InternalsVisibleTo("MyLib.NUnit, PublicKey=<your public key>")]
#endif
In other words, MyLib.NUnit must also be signed in Release configuration.
You can use preprocessor directives:
#if SIGN
//Only the Release build is signed
#pragma warning disable 1699 //We can't use the compiler switch
[assembly: AssemblyKeyName("KeyContainerName")]
#pragma warning restore 1699
#endif
Then define the SIGN symbol in the Release configuration.
You must install the key into a key container using sn.exe. Alternatively, you can use [AssemblykeyFile] to specify a path.
The #pragma suppresses this warning.